JP6973227B2 - 異常トラヒック分析装置、異常トラヒック分析方法及び異常トラヒック分析プログラム - Google Patents

Description

本発明は、ＳＩＥＭ（Security Information and Event Management）、セキュリティエンジン、ヘテロジーニアスネットワーク等に適用可能な異常トラヒック分析装置、異常トラヒック分析方法及び異常トラヒック分析プログラムに関する。

近年、ＩｏＴ（Internet of Things）機器の普及により、多数のＩｏＴ機器がネットワークに接続され、大量のトラヒックが発生するようになっている。また、ＩｏＴ機器は、制御などの用途から、ＩＴ機器と比べ低遅延が要求される場合がある。このような傾向から、ネットワークや情報処理にかかわるアーキテクチャの変更が必要であり、その選択肢として、複数の通信方法（通信経路）を使い分けることにより、より効率的にネットワークトラヒックを捌くことが提案されている。

一方、ネットワークを介して提供される各種サービスや、インフラなどに対して攻撃する不正な通信（サイバー攻撃）は、多種多様な手法を用いたものへと変化し、ますます脅威が増大している。従来では、このような不正な通信に対する対策として、不正な通信（異常トラヒック）を検出する装置がネットワークに設けられている。

特許第５８４４９３８号公報 特願２０１７−０１２５５８

従来では、１つの対象とするＩｏＴ機器からのトラヒックは、例えばＬＴＥ（Long Term Evolution）など特定の１つの通信方式を用いて送信することを想定している。このため、不正な通信（異常トラヒック）を検出する装置は、トラヒックの送信に用いられる特定の通信方式に最適化された分析アルゴリズムを用いてトラヒックを分析している。

従って、ネットワークに大量のトラヒックが発生することに対して、１つのＩｏＴ機器からトラヒックを送信する際に、アプリケーション側で通信方式を選択し、発生するトラヒック内容が変更されてしまうと、トラヒックに対して適切な分析ができない状況が発生する可能性がある。

本発明は上記課題を解決するためになされたものであり、本発明の目的は、機器からトラヒックが送信される通信経路に関係なく適切な分析をすることが可能な異常トラヒック分析装置、異常トラヒック分析方法及び異常トラヒック分析プログラムを提供することにある。

本発明は、課題を解決するために、以下のような手段を講じている。

本発明の第１の態様は、異常トラヒック分析装置は、１つの機器から異なる通信方式を用いた複数の通信経路を介してトラヒックを受信する受信手段と、前記トラヒックが送信された通信経路を特定する複数通信管理手段と、前記複数通信管理手段により特定された通信経路に対応する、不正な通信による前記トラヒックの脅威のレベルを判定するための分析アルゴリズムを決定する分析方法決定手段と、前記分析方法決定手段により決定された分析アルゴリズムを用いて、前記トラヒックの脅威のレベルを判定する分析手段と、前記分析手段による分析結果を記録させる分析結果記録手段とを有する。

本発明によれば、特定された通信経路に応じた適切な分析アルゴリズムを用いてトラヒックに対して分析を実施するので、異常トラフィックの検知率の向上が可能となる。

本実施形態の通信システムの一例を示す図。 本実施形態の通信システムの一例を示す図。 本実施形態における異常トラフィック分析装置の構成を示すブロック図。 本実施形態における異常トラフィック検知エンジンの機能構成を示すブロック図。 本実施形態における監視対象情報管理サーバの動作を示すフローチャート。 監視対象情報管理サーバにおいて管理される管理テーブルの一例を示す図。 異常トラフィック分析装置の処理の流れを示す図。

以下、本実施形態について、図面を参照しながら説明する。
図１及び図２は、本実施形態の通信システムの一例を示す図である。図１及び図２に示す通信システムは、例えば自動車等を自動走行させるための自律型モビリティシステムを実現するシステムである。自律型モビリティシステムは、例えば自動車等に設けられた各種のセンサや機器等により検出された各種のデータ（プローブデータ）を、例えば、自動車に搭載されたＩｏＴ機器４０からサーバに送信する。自律型モビリティシステムは、多数の自動車等のＩｏＴ機器から受信されたプローブデータをリアルタイムでダイナミックマップに反映させ、このダイナミックマップのデータを自動車のＩｏＴ機器に送信する。自動車は、ダイナミックマップのデータをもとに自動走行の制御を実行する。

本実施形態における通信システムでは、ネットワークに大量に発生するトラヒックを効率的に送受信するため、自動車等に搭載されたＩｏＴ機器とサーバとのデータ（トラヒック）の送受信を、異なる通信方式を用いた複数の通信経路の何れかを用いて行う。本実施形態では、複数の通信方法として、例えばモバイルネットワーク（移動網３３）を使用するＬＴＥ（Long Term Evolution）通信と、インターネット１６を用いたＷｉ−Ｆｉ通信の何れかを選択して用いることができるものとする。

なお、ＬＴＥ通信とＷｉ−Ｆｉ通信に限るものではなく、他の通信方法を用いることもできる。さらに、２つの通信方法に限らず、３つ以上の通信方法を選択して用いることができるようにしても良い。

図１に示す通信システムでは、インターネット１６上にコアネットワーク１０（１０−１，…，１０−ｍ）が設けられる。コアネットワーク１０には、例えばクラウドサーバ１２、ダイナミックマップサーバ１４、監視対象情報管理サーバ１５が設けられる。クラウドサーバ１２は、各種サービスに対応するサーバである。クラウドサーバ１２には、Ｗｉ−Ｆｉ通信方式による通信経路を介してインターネット１６に接続されたＩｏＴ機器を識別する認証サーバを含む。

監視対象情報管理サーバ１５は、自動車等に搭載された端末（ＵＥ：User Equipment）など、監視対象とするＩｏＴ機器４０に関する情報を管理するサーバである。監視対象情報管理サーバ１５は、例えば端末が利用するサービス、端末がデータを送受信するエッジ（ローカルネットワーク２０）、端末の現在位置に対応するセル（基地局３２）の対応関係等を管理する。監視対象情報管理サーバ１５は、自動車の走行に伴って端末（ＩｏＴ機器）が、異なるローカルネットワーク２０に対応するセル（基地局３２）の範囲に移動したことが検出された場合、複数のローカルネットワーク２０（２０−１，…，２０−ｎ）のそれぞれに含まれる異常トラフィック分析装置２８（２８−１，…，２８−ｎ）に対して、対象とするＩｏＴ機器が移動したことを通知するメッセージを同報配信する。

また、監視対象情報管理サーバ１５は、監視対象とするＩｏＴ機器について、認証サーバ及び移動網３３内に設けられた移動網の管理サーバ（図示せず）からのメッセージを受信して、ＩｏＴ機器を特定する一意の識別子（ＩｏＴ識別子）と対応づけて、監視対象とするＩｏＴ機器のＷｉ−Ｆｉ通信方式による通信とＬＴＥ通信方式による通信の状況を統合的に管理する。

ダイナミックマップサーバ１４は、複数のＩｏＴ機器から受信されるデータ（プローブデータ）をもとにダイナミックマップを作成して、ダイナミックマップデータを端末（ＩｏＴ機器）に配信する。ダイナミックマップサーバ１４は、例えば、ローカルネットワーク２０（２０−１，…，２０−ｎ）のダイナミックマップサーバ２４（２４−１，…，２４−ｎ）が管理するダイナミックマップより上位のダイナミックマップを対象とする。

ローカルネットワーク２０（２０−１，…，２０−ｎ）は、通信システム（自律型モビリティシステム）をエッジコンピューティング方式により実現するためのネットワークである。すなわち、コアネットワーク１０よりもＩｏＴ機器（端末）に近い位置に、自律型モビリティシステムのサービスを提供するネットワークスライスを構成している。これにより、ＩｏＴ機器とサーバとの間の低遅延通信を実現している。エッジコンピューティング方式による通信システムでは、サービスを提供するエッジサーバ２２（２２−１．…，２２−ｎ）が、複数のローカルネットワーク２０−１，…，２０−ｎに分散して配置される。

図２には、１つのローカルネットワーク２０と、例えば自動車に搭載されたＩｏＴ機器４０との関係を示している。

ローカルネットワーク２０には、自律型モビリティシステムのサービスを提供するために、ダイナミックマップサーバ２４、プローブ収集サーバ２６、ゲートウェイ２７、異常トラフィック分析装置２８が配置される。なお、ローカルネットワーク２０−１，…，２０−ｎは、それぞれ同様に構成されるものとして、個々について詳細な説明を省略する。

ダイナミックマップサーバ２４は、プローブ収集サーバ２６により収集される複数のＩｏＴ機器４０からのデータ（プローブデータＰＤ）をもとにダイナミックマップを作成して、ゲートウェイ２７を通じて、ダイナミックマップデータＤＭＤをＩｏＴ機器４０に配信する。ダイナミックマップサーバ２４は、コアネットワーク１０に設けられたダイナミックマップサーバ１４よりもローカルな範囲のダイナミックマップを管理する。

プローブ収集サーバ２６は、複数のＩｏＴ機器４０から送信されるデータ（プローブデータＰＤ）を、ゲートウェイ２７を通じて受信して記録する。プローブ収集サーバ２６は、ＩｏＴ機器４０から収集したプローブデータをダイナミックマップサーバ２４に提供する。プローブデータには、自動車の走行位置、車速、ブレーキング、燃費など、様々なデータを含む。

ゲートウェイ２７は、ローカルネットワーク２０（ネットワークスライス）と他のネットワークとを接続する。ゲートウェイ２７は、例えば、Ｗｉ−Ｆｉアクセスポイント３０と接続されたＩｏＴ機器４０からのデータを、インターネット１６を通じて受信する。また、ゲートウェイ２７は、基地局３２と接続されたＩｏＴ機器４０からのデータを、移動網３３を通じて受信する。ゲートウェイ２７は、異常トラフィック分析装置２８と連携し、異常トラフィック分析装置２８による分析によって異常と判断された、例えば悪意のあるＩｏＴ機器４２から送信される異常トラヒックを遮断する機能を有する。

異常トラフィック分析装置２８は、ゲートウェイ２７と連携して動作し、異常トラヒックを検出するための異常トラフィック検知エンジンとして動作する。異常トラフィック分析装置２８は、ゲートウェイ２７を通じて送受信されるトラヒック（ミラーリングトラヒック）を入力して分析し、例えば悪意のあるＩｏＴ機器４２から送信される異常トラフィックの検知・判断を実行する。

図３は、本実施形態における異常トラフィック分析装置２８の構成を示すブロック図である。
異常トラフィック分析装置２８は、プログラムを実行するコンピュータを備えており、プロセッサ２８Ａ、メモリ２８Ｂ、通信インタフェース２８Ｃ、記憶装置２８Ｄを有する。

プロセッサ２８Ａは、例えばＣＰＵ（Central Processing Unit）であり、メモリ２８Ｂに記憶されたプログラムを実行することで、異常トラフィック分析装置２８の各部を制御する。プロセッサ２８Ａは、異常トラフィック分析プログラムＰを実行することで、ゲートウェイ２７を通じて送受信される異常トラヒックを検出するための異常トラフィック検知エンジン（図４に示す）を実現する。異常トラフィック検知エンジンには、機能モジュール及びデータベースを含む。

メモリ２８Ｂは、プロセッサ２８Ａによる処理の作業エリアとして使用され、プログラムやデータが記憶される。

通信インタフェース２８Ｃは、プロセッサ２８Ａのもとで通信を制御する。

記憶装置２８Ｄは、例えばＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）であり、プロセッサ２８Ａにより実行されるプログラム、各種データが記憶される。記憶装置２８Ｄに記憶されるプログラムには、異常トラヒック分析プログラムＰを含む。また、異常トラヒック分析プログラムＰの実行に伴い、トラヒックデータデータベースＤＢ１、ＵＥ別脅威レベルデータベースＤＢ２、分析結果ログＤＢ３等が記憶される。

図４は、本実施形態における異常トラフィック検知エンジン５０の機能構成を示すブロック図である。異常トラフィック検知エンジン５０は、プロセッサ２８Ａにより異常トラフィック分析プログラムＰを実行することにより実現される。

異常トラフィック検知エンジン５０の機能モジュール５２には、トラヒック受信解析部Ｍ１、分析方法決定部Ｍ２、分析部Ｍ３、分析結果取得部Ｍ４、複数通信管理部Ｍ５が含まれる。また、機能モジュール５２により処理されるデータを記憶するデータベース５４として、トラヒックデータデータベースＤＢ１、ＵＥ別脅威レベルデータベースＤＢ２、分析結果ログＤＢ３が設けられる。

トラヒック受信解析部Ｍ１は、ゲートウェイ２７に送受信されるトラヒックと同じトラヒック（ミラーリングトラヒック）を受信する。トラヒック受信解析部Ｍ１により受信されるトラヒックは、１つのＩｏＴ機器４０から異なる通信方式（ＬＴＥ通信、Ｗｉ−Ｆｉ通信）を用いた複数の通信経路を介して受信されたトラヒックを含む。トラヒック受信解析部Ｍ１は、トラヒックデータの記録、トラヒック（ヘッダ部及びペイロード部）についての解析、複数通信管理部Ｍ５に対するパケットの通信経路の問い合わせ、通信経路を示すデータを含むエントリデータの生成等を実行する。

分析方法決定部Ｍ２は、複数通信管理部Ｍ５により特定された通信経路に応じて、トラヒックの異常を検出するための分析アルゴリズム、及び分析アルゴリズムに従う分析に使用されるパラメータを決定する。

分析部Ｍ３は、トラヒックデータに対する分析を実行する。分析部Ｍ３は、トラヒックが送信される複数の通信経路（通信方法）のそれぞれに対応する複数の分析アルゴリズムを有し、分析方法決定部Ｍ２によって決定された分析アルゴリズム及びパラメータに応じてトラヒックに対する分析を実行する。

分析結果取得部Ｍ４は、分析部Ｍ３による分析結果を取得して記録させる。

複数通信管理部Ｍ５は、トラヒック受信解析部Ｍ１により受信されるトラヒックの通信経路を管理し、トラヒック受信解析部Ｍ１からの問い合わせに応じて通信経路を特定する。

次に、本実施形態の通信システムにおける異常トラフィックの検出のための動作について説明する。
まず、監視対象情報管理サーバ１５によるＩｏＴ機器４０のＷｉ−Ｆｉ通信方式による通信とＬＴＥ通信方式による通信の状況を統合的に管理する処理について説明する。

図５は、本実施形態における監視対象情報管理サーバ１５の動作を示すフローチャートである。ここでは、図５に示すＵＥ情報管理処理（ステップＳ２）について説明する。図６は、監視対象情報管理サーバ１５において管理される管理テーブルの一例を示す図である。

ＩｏＴ機器４０は、例えば自機器の動作状況や自動車の位置などに応じて通信経路（通信方法）を切り替えて、例えばプローブデータの送信を継続する。

監視対象情報管理サーバ１５は、ＩｏＴ機器４０の動作状況を監視するため、ＩｏＴ機器４０がＬＴＥ通信を利用する場合には、移動網３３の管理サーバからのメッセージを受信する。管理サーバからのメッセージでは、ＵＥ識別情報が通知される（ステップＳ２１）。

監視対象情報管理サーバ１５は、ＵＥ識別情報の通知に応じて、管理テーブルにＩｏＴ機器４０に固有のＩｏＴ識別子（ＵＥ情報）と通信回線に対応する識別子や属性情報を対応させて保持する。通信回線に関する識別子は、例えばＩＭＳＩ（International Mobile Subscriber Identity）と対応づけた端末識別子（ＵＥ識別子）とする。また、メッセージ中のＩＰアドレス／ＵＥ状態の値で、ＬＴＥ ＩＰアドレス／接続状態を示す属性情報となるデータを更新する（ステップＳ２２）。Ｗｉ−Ｆｉについては、認証サーバによって認証され、Ｗｉ−Ｆｉ識別子とＩＰアドレスの対応が特定されてメッセージにより通知される。ＩｏＴ識別子に対応するＩＭＳＩ及びＷｉ−Ｆｉ識別子が示すＩｏＴ機器では、予め使用できる通信経路（ここでは、ＬＴＥ通信、Ｗｉ−Ｆｉ通信）が特定されている。従って、管理テーブルでは、ＬＴＥ通信とＷｉ−Ｆｉ通信のそれぞれの使用状況を示すデータを、ＩｏＴ識別子により紐付けて管理する。前述の図６に示す管理テーブルを保持しているため、ＩＭＳＩやＷｉ−Ｆｉ識別子が逐次、更新されることにより、ＩｏＴ機器４０が複数の通信経路の何れかに切り替えて用いた際に、トラヒックがどの通信方式による通信経路を通じて送信されたか特定することが可能になる。図６に示す管理テーブルの情報が更新されるたびに逐次的に異常トラフィック分析装置２８（本実施形態におけるセキュリティエンジン）の複数通信管理部Ｍ５に対して送付することにより、トラヒックを分析する際にどのＩＰアドレスのトラヒックがどの通信方式かを検索することができる。

監視対象情報管理サーバ１５は、ＩｏＴ機器４０の動作状況を監視するため、ＩｏＴ機器４０がＷｉ−Ｆｉ通信を利用する場合には、クラウドの認証サーバからのメッセージを受信する。認証サーバ（Ｗｉ−Ｆｉ認証機能）からのメッセージでは、Ｗｉ−Ｆｉ識別子とＷｉ−Ｆｉ ＩＰアドレスが通知される（ステップＳ２１）。

監視対象情報管理サーバ１５は、メッセージにより通知されたＷｉ−Ｆｉ識別子とＷｉ−Ｆｉ ＩＰアドレスをもとに、ＩｏＴ識別子（ＵＥ情報）に対応するＷｉ−Ｆｉ識別子やＷｉ−Ｆｉ ＩＰアドレスを更新する（ステップＳ２３）。

こうして、管理テーブルでは、ＩｏＴ識別子により特定されるＩｏＴ機器が使用する通信経路の状況が管理される。従って、異常トラフィック分析装置２８において受信されるトラヒックに含まれるＩｏＴ機器に固有の識別子をもとに、管理テーブルを参照することにより、トラヒックが送信された通信経路（通信方法）を特定することができる。

次に、本実施形態における異常トラフィック分析装置２８の動作について、図４及び図７を参照しながら説明する。図７は、異常トラフィック分析装置２８（異常トラフィック検知エンジン５０）の処理の流れを示す図である。

（１）まず、トラヒック受信解析部Ｍ１は、トラヒックを受信すると、トラヒックデータＤ２を生成してトラヒックデータベースＤＢ１へ書き出す。

（２）トラヒック受信解析部Ｍ１は、トラヒックに対して構文解析して、ヘッダ部に付加された送信元とするＩｏＴ機器に固有の識別子の抽出の他、分析対象のパケットの選別、ＩＰ（internet protocol）パケットヘッダにある５ｔｕｐｐｌｅ情報（送信元アドレス、宛先アドレス、送信元ポート番号、宛先ポート番号、プロトコル情報）等の共通情報と、ペイロード情報等を取得する。ＩｏＴ機器に固有の識別子は、例えばＩＰアドレスあるいはＩｏＴ機器の端末識別子（ＵＥ識別子）である。

トラヒック受信解析部Ｍ１は、ＩｏＴ機器に固有の識別子をもとに、複数通信管理部Ｍ５にトラヒックの通信経路を問い合わせる。複数通信管理部Ｍ５は、トラヒック受信解析部Ｍ１からの問い合わせに応じて、監視対象情報管理サーバ１５に通信経路を問い合わせる。

監視対象情報管理サーバ１５は、複数通信管理部Ｍ５からのＩｏＴ機器に固有の識別子をもとにした問い合わせを受信し（ステップＳ１）、ＩｏＴ機器に固有の識別子に応じた問い合わせ種別を判別する（ステップＳ１２）。

複数通信管理部Ｍ５から受信した識別子が端末識別子（ＵＥ識別子）の場合、監視対象情報管理サーバ１５は、管理テーブルを参照して、ＵＥ識別子に対応するＬＴＥ ＩＰアドレスとＷｉ−Ｆｉ ＩＰアドレスをもとに通信経路を特定する（ステップＳ１３）。

一方、複数通信管理部Ｍ５から受信した識別子がＩＰアドレスの場合、監視対象情報管理サーバ１５は、管理テーブルを参照して、受信したＩＰアドレスに対応するＵＥ識別子と通信経路を特定する（ステップＳ１４）。

監視対象情報管理サーバ１５は、特定した通信経路を示すデータを複数通信管理部Ｍ５に返却する。

異常トラフィック分析装置２８の複数通信管理部Ｍ５は、監視対象情報管理サーバ１５から通知された通信経路（通信方法）をトラヒック受信解析部Ｍ１に通知する。トラヒック受信解析部Ｍ１は、複数通信管理部Ｍ５から取得された通信方式（通信経路）を示すデータをエントリデータＤ１に加える。

なお、前述した説明では、複数通信管理部Ｍ５は、トラヒック受信解析部Ｍ１からの要求に応じて、監視対象情報管理サーバ１５に対して問い合わせするとしているが、監視対象情報管理サーバ１５から管理テーブルを取得しておき、この管理テーブルを参照して通信経路（通信方法）を特定するようにしても良い。管理テーブルのデータは、特定の範囲にあるＩｏＴ機器について、状況の変化があった場合に監視対象情報管理サーバ１５から取得することができる。

（３）トラヒック受信解析部Ｍ１は、さらに、構文解析により得られた各情報、複数通信管理部Ｍ５により特定された通信経路を示すデータとを含むエントリデータＤ１を生成して、分析方法決定部Ｍ２へ引渡す。

（４）分析方法決定部Ｍ２は、受け取ったエントリデータＤ１をもとに、分析部Ｍ３における分析で用いる分析アルゴリズム及びパラメータを決定し、これらの分析方法を示すデータをエントリデータＤ１に付加して分析部Ｍ３へ引渡す。すなわち、トラヒックが送信された通信経路（通信方法）に応じた、最適な分析アルゴリズムとパラメータが決定され、分析部Ｍ３に指示される。

（５）分析部Ｍ３は、受け取ったエントリデータＤ１に対応するトラヒックデータＤ２を、トラヒックデータベースＤＢ）から取得する。

（６）分析部Ｍ３は、分析方法決定部Ｍ２において決定された分析方法（分析アルゴリズム、パラメータ）を用いて、エントリデータＤ１について分析し、その分析結果Ｄ３及びエントリデータＤ１を分析結果取得部Ｍ４へ引渡す。分析部Ｍ３は、例えば攻撃検知の詳細度（次数）の再設定を繰り返しながら分析して、対象エントリ別の脅威レベルを判定する分析を実行する。分析の具体例については後述する。

（７）分析結果取得部Ｍ４は、受け取った分析結果Ｄ３から対象エントリ別脅威レベルＤ４（後述する）を取得して、監視対象のＩｏＴ機器の脅威レベルを決定するためのルールに適用してＵＥ別脅威レベルを決定し、ＵＥ別脅威レベルデータベースＤＢ２を更新する。

（８）分析結果取得部Ｍ４は、更に、受け取った分析結果Ｄ３を分析結果ログＤＢ３へ保存する。

（９）分析結果取得部Ｍ４は、分析結果Ｄ３から対象エントリ別脅威レベルＤ４を取得し、次の分析が必要な該当エントリデータＤ１および対象エントリ別脅威レベルＤ４を分析方法決定部Ｍ２へ引渡す。

なお、（３）分析方法決定部Ｍ１は、１つ前の分析次数および対象エントリ別脅威レベルと該当エントリデータＤ１を、分析次数決定ルールにより分析方法を決定して分析方法が付加されたエントリデータを分析部Ｍ３へ引渡す。

ここで、分析部Ｍ３による分析の具体例について説明する。
ＵＥ別脅威レベルデータベースＤＢ２には、過去の通信を対象として、発信元を特定する情報（例えばＩＰアドレスや端末ＩＤ）に紐づけて、一次検知（分析Ａ）の検知結果、二次検知（分析Ｂ）の検知結果、…といった具合に、攻撃検知の詳細度（以下、次数ともいう）ごとに、攻撃検知の結果が記憶されている。これに加え、ＵＥ別脅威レベルデータベースＤＢ２には、詳細度ごとの攻撃検知結果から導き出される脅威レベルが対応付けられて記憶されている。

脅威レベルは、０または１の２値としてもよいし、３値以上の数値を設定してもよい。例えば脅威レベルに１０種類の数字０，１，…，９を設定し、数字が大きければ大きいほど悪性度が強いことを意味するものとし、脅威レベルカラムの数字が９であれば明らかな悪性としてもよい。

ＵＥ別脅威レベルデータベースＤＢ２には、少なくとも、過去に受信した情報の発信元（例えばＩＰアドレスや端末ＩＤ）と過去に受信した情報の脅威レベルとが対応付けられてエントリデータとして予め記憶されているものとする。

分析部Ｍ３は、ＵＥ別脅威レベルデータベースＤＢ２の各エントリと特定された発信元とを照合し、受信した情報に対する攻撃検知の詳細度を決定する。より具体的には、分析部Ｍ３は、発信元が特定されたトラヒックに対し、これと同一の発信元に該当するエントリがＵＥ別脅威レベルデータベースＤＢ２に存在するか否かを確認する。分析部Ｍ３は、例えば以下のような分数次数決定ルール（１）（２）で、受信した情報に対する攻撃検知の詳細度を決定してもよい。

（１）具体例
ＵＥ別脅威レベルデータベースＤＢ２に対応するエントリがなかった場合、詳細度（次数）を１次と設定する。一方、ＵＥ別脅威レベルデータベースＤＢ２に対応するエントリがあった場合、詳細度（次数）をエントリが示す脅威レベルの一つ上の次数に設定する。

（２）具体例
ＵＥ別脅威レベルデータベースＤＢ２に対応するエントリがなかった場合、詳細度（次数）を１次と設定する。一方、ＵＥ別脅威レベルデータベースＤＢ２に対応するエントリがあった場合、詳細度（次数）をエントリが示す脅威レベルと等しい次数に設定する。

本実施形態の異常トラフィック分析装置２８では、トラヒックが送信された通信経路（通信方法）に応じて、攻撃検知アルゴリズムと詳細度（次数）が決定されるものとする。本実施例で用いることができる攻撃検知アルゴリズムとしては、例えばルールベース攻撃検知、ポートスキャニングの検知、利用ポートの変化検知、トラヒック流量の変化検知、パケット受信タイミングの変化検知、ＤＰＩ、時系列データとして取得されたデータを用いて予測されたデータと、実測されたデータとのはずれ具合で異常を検知する攻撃検知などが挙げられる。攻撃検知アルゴリズムが詳細かつ高コストであるほど、詳細度（次数）が高く設定される。

次に、分析部Ｍ３は、受信したトラヒックに対して、決定された詳細度（次数）（分析パラメータ）に基づく攻撃検知を実行する。

攻撃検知の結果が正常であった場合、分析部Ｍ３は、分析結果Ｄ３を分析結果取得部Ｍ４に渡す。分析結果取得部Ｍ４は、発信元を特定する情報と検知結果（対象エントリ別脅威レベルＤ４）を分析結果ログＤＢ３およびＵＥ別脅威レベルデータベースＤＢ２に保存する。分析結果ログＤＢ３には、アノマリ識別子、タイムスタンプ、発信元を特定する情報（ＩＰアドレスや端末ＩＤ）、詳細度ごとの検知結果、詳細度ごとの検知回数、最終検知結果、対処済フラグなどが保存される。

一方、攻撃検知の結果が正常でない場合（懸念有、または異常有であった場合）、分析部Ｍ３は、受信したトラヒックに対する高次な攻撃検知の必要性を判断する。高次な攻撃検知の必要性があると判断されなかった場合、分析結果取得部Ｍ４は、分析部Ｍ３による分析結果として、発信元を特定する情報と、検知結果を分析結果ログＤＢ３およびＵＥ別脅威レベルデータベースＤＢ２に保存する。

攻撃検知の結果が正常でない場合として、具体的には以下のようなケース（１）（２）が考えられる。（１）該当の通信が異常（不正）であることが明白であるため、さらに高次な攻撃検知を実行する必要性が乏しい。例えば、前述の脅威レベルカラムの数字が９である場合などには、該当の通信が悪性であることが明白であるため、さらに高次な攻撃検知を省略することができ、計算リソースを効果的に用いることができる。（２）すでに最高次の攻撃検知が実行されており、これよりも高次な攻撃検知が実行できない。

一方、高次な攻撃検知の必要性があると判断された場合、分析部Ｍ３は、攻撃検知の結果に基づいて、受信した情報に対する攻撃検知の詳細度を再度決定する。分析部Ｍ３は、再度決定された詳細度（次数）に基づく攻撃検知を再度実行する。攻撃検知の結果が正常でないと判断される場合、分析部Ｍ３は、さらに高次な攻撃検知の必要性を判断する。このように、攻撃検知の結果が正常でないと判断される限りにおいて、繰り返し実行される。分析部Ｍ３の詳細度（次数）の再決定方法として以下の具体的方法（１）〜（４）が考えられる。

（１）具体例
対象の攻撃検知の詳細度（次数）を常に１増やす。

（２）具体例２
攻撃検知アルゴリズムの出力が、正常／懸念有り／異常有りの３段階で表現される場合、
出力＝懸念有り→判断結果＝Ｙｅｓ（次数を１増やす）
出力＝異常有り→判断結果＝Ｙｅｓ（次数を２増やす）
（３）具体例
攻撃検知アルゴリズムの出力が、正常／懸念有り／異常有りの３段階で表現される場合、
出力＝懸念有り→判断結果＝Ｎｏ（次数を増やさない→Ｓ１５ａＮ→エンド）
出力＝異常有り→判断結果＝Ｙｅｓ（次数を１増やす）
（４）具体例
攻撃検知アルゴリズムの出力が、異常の有無を数値で表現する場合。例えば、攻撃検知アルゴリズムの出力が０．０〜１．０であって、値が１．０に近づくほど異常性が高く、異常有無判断の閾値が０．５だった場合。

出力＝０．５以上０．６未満→判断結果＝Ｙｅｓ（次数を１増やす）
出力＝０．６以上０．７未満→判断結果＝Ｙｅｓ（次数を２増やす）
出力＝０．７以上０．８未満→判断結果＝Ｙｅｓ（次数を３増やす）
出力＝０．８以上０．９未満→判断結果＝Ｙｅｓ（次数を４増やす）
出力＝０．９以上→判断結果＝Ｙｅｓ（次数を５増やす）
本実施例の異常トラフィック分析装置２８によれば、危険性の低いＩｏＴ機器（機器）については、早々に攻撃検知を打ち切るため、計算リソースが無駄にならない。

また、明らかに不正なＩｏＴ機器についても同様に、早々に攻撃検知を打ち切るため、計算リソースが無駄にならない。

また、該当のＩｏＴ機器の危険性がグレーゾーンにある場合は、処理を繰り返し実行することにより、攻撃検知の信頼性が担保される。

また、ＵＥ別脅威レベルデータベースＤＢ２にエントリとして登録されているＩｏＴ機器については、登録済みの脅威レベルに応じた詳細度が最初に設定されるため、詳細度の低い攻撃検知が適宜スキップされ、計算リソースが無駄にならない。

このように、本実施例の異常トラフィック分析装置２８によれば、計算リソースを効果的に用いることができる。

なお、前述したトラヒックに対する分析は一例であって、他の分析を対象とすることができる。その場合、前述と同様にして、トラヒックの通信経路を特定し、それにあわせて、分析アルゴリズムおよび分析パラメータを選択する。例えば、ＤＯＳ（Denial of Service attack）攻撃検知のための分析をする場合において、閾値を通信方式に応じて変更する。

このようにして、本実施形態における異常トラフィック分析装置２８では、トラヒックが送信された通信経路（通信方法）を特定し、通信経路（通信方法）に応じた分析アルゴリズム及び分析パラメータを用いてトラヒックに対する分析を実行する。従って、ＩｏＴ機器４０のアプリケーションにより通信経路が変更されたとしても、通信経路に関係なく適切な分析をすることが可能となり、異常トラフィックの検知率の向上が可能となる。

また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フレキシブルディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。

また、本発明は、前述した実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前述した実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１０（１０−１，…，１０−ｍ）…コアネットワーク、１２…クラウドサーバ、１４…ダイナミックマップサーバ、１６…インターネット、２０（２０−１，…，２０−ｎ）…ローカルネットワーク、２２（２２−１．…，２２−ｎ）…エッジサーバ、２４（２４−１，…，２４−ｎ）…ダイナミックマップサーバ、２６（２６−１，…，２６−ｎ）…プローブ収集サーバ、２７（２７−１，…，２７−ｎ）…ゲートウェイ、２８（２８−１，…，２８−ｎ）…異常トラフィック分析装置、２８Ａ…プロセッサ、２８Ｂ…メモリ、２８Ｃ…通信インタフェース、２８Ｄ…記憶装置、３０…Ｗｉ−Ｆｉアクセスポイント、３２…基地局、Ｍ１…トラヒック受信解析部、Ｍ２…分析方法決定部、Ｍ３…分析部、Ｍ４…分析結果取得部、Ｍ５…複数通信管理部、ＤＢ１…トラヒックデータデータベース、ＤＢ２…ＵＥ別脅威レベルデータベース、ＤＢ３…分析結果ログ。

Claims (5)

1. １つの機器から異なる通信方式を用いた複数の通信経路を介してトラヒックを受信する受信手段と、
   前記トラヒックが送信された通信経路を特定する複数通信管理手段と、
   前記複数通信管理手段により特定された通信経路に対応する、不正な通信による前記トラヒックの脅威のレベルを判定するための分析アルゴリズムを決定する分析方法決定手段と、
   前記分析方法決定手段により決定された分析アルゴリズムを用いて、前記トラヒックの脅威のレベルを判定する分析手段と、
   前記分析手段による分析結果を記録させる分析結果記録手段と
   を有する異常トラヒック分析装置。
2. 前記複数通信管理手段は、前記トラヒックに含まれる識別子をもとに、前記機器による通信の状況を管理する外部サーバに問い合わせて、前記トラヒックが送信された通信経路を示すデータを取得する請求項１記載の異常トラヒック分析装置。
3. 前記分析方法決定手段は、前記複数通信管理手段により特定された通信経路に応じた分析アルゴリズムで使用する分析パラメータを、前記通信経路に応じて変更する請求項１記載の異常トラヒック分析装置。
4. １つの機器から異なる通信方式を用いた複数の通信経路を介してトラヒックを受信する受信工程と、
   前記トラヒックが送信された通信経路を特定する複数通信管理工程と、
   前記複数通信管理工程により特定された通信経路に対応する、不正な通信による前記トラヒックの脅威のレベルを判定するための分析アルゴリズムを決定する分析方法決定工程と、
   前記分析方法決定工程により決定された分析アルゴリズムを用いて、前記トラヒックの脅威のレベルを判定する分析工程と、
   前記分析工程による分析結果を記録させる分析結果記録工程とを有する異常トラヒック分析方法。
5. 請求項１乃至３の何れかに記載の異常トラヒック分析装置が具備する各手段が行う処理を、当該異常トラヒック分析装置が備えるコンピュータに実行させる異常トラヒック分析プログラム。

Images