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

Description

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

近年、ＩｏＴ機器の普及により、多数のＩｏＴ機器がネットワークに接続し、大量のトラヒックを発生するようになった。また、ＩｏＴ機器は、制御などの用途から、ＩＴ機器と比べ低遅延が要求される場合がある。このような傾向から、ネットワークや情報処理にかかわるアーキテクチャの変更が必要であり、その選択肢として、サーバクライアント型におけるサーバは、エッジコンピューティング方式が提案されている。

エッジコンピューティングにおいては、サーバが分散して配置される。ＩｏＴ機器（以下ＵＥともいう）においても、ＩＴ機器と同様にセキュリティ対策をすることが求められる。

「豊かな生活に役立つ社会基盤となるＬＴＥサービス「Ｘｉ」（クロッシィ）」、NTT技術ジャーナル、pp.48-51、2011.7

従来の分散連携方式の代表例である移動局のハンドオーバ技術は、ＩｏＴ機器（ＵＥ）の通信先である基地局が他の基地局に移動した場合に移動端末とネットワークの連携を行う方式である。エッジに分散配置された多層型セキュリティ分析エンジンは、過去のトラヒックデータを用いて分析を行う場合があるため、基地局間移動時にデータの移動先への送付が不可欠である。基地局間で連携するという既存技術は存在するものの、エッジ間のセキュリティエンジンに適応させるためには、検知に必要な情報について送付しないといけないが、既存技術では考慮されていないという課題がある
本発明は上記課題を解決するためになされたものであり、本発明の目的は、ＩｏＴ機器がエッジ間を移動したとしても適切に情報連携してシームレスな分析が可能な異常トラヒック分析装置、異常トラヒック分析方法及び異常トラヒック分析プログラムを提供することにある。

本発明は、課題を解決するために、以下のような手段を講じている。
本発明の第１の態様は、異常トラヒック分析装置は、機器からのトラヒックを受信する受信手段と、前記機器からのトラヒックが異常トラヒックであるかを、異常の詳細度の再設定を繰り返しながら分析して、脅威レベルを判定する分析手段と、前記分析手段による分析結果を記録させる分析結果記録手段と、前記機器のエッジ間の移動を管理する機器管理手段とを有し、前記機器管理手段により前記分析手段により分析の対象としている機器が他のエッジへ移動することが判定される場合に、前記受信手段は、前記機器からのトラヒックについて、前記機器からのトラヒックに応じたトラヒックデータ、過去に受信した情報の発信元と過去に受信した情報の脅威レベルとが対応付けられたエントリデータ、及び前記機器に対応する脅威レベルを示すデータの何れかをもとに分析を継続するための情報を生成して、前記機器に対応する脅威レベルをもとに、分析を継続するための情報を送信するか否かを判断し、この判断結果に基づいて、前記機器の移動先とするエッジに含まれる、トラヒックを分析する装置に、分析を継続するための情報を送信する。

本発明によれば、ＩｏＴ機器がエッジ間を移動したとしても適切に情報連携してシームレスな分析が可能となる。

本実施形態の通信システムの一例を示す図。 図１に示す通信システムにおける分散協調セキュリティ分析技術の概略を説明するための図。 セルとエッジとサービスの関係の一例を示す図。 セルとエッジとサービスの関係の他の一例を示す図。 セルとエッジとサービスの関係を表すデータ構造の一例を示す図。 セルとエッジとサービスの関係を示すエッジサービスセル対応情報（管理データ）の一例を示す図。 本実施形態における異常トラフィック分析装置の構成を示すブロック図。 本実施形態における異常トラフィック検知エンジンの機能構成を示すブロック図。 異常トラフィック分析装置の処理の流れを示す図。 移動元側／移動先側の異常トラフィック分析装置の処理の流れを示す図。 移動元側／移動先側の異常トラフィック分析装置による分散協調の処理を示すフローチャート。 分散協調管理部の動作を示すフローチャート。

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

本実施形態における通信システムでは、自動車等に搭載されたＩｏＴ機器とサーバとのデータ（トラヒック）の送受信を、例えばモバイルネットワーク（移動網３３）を使用するＬＴＥ（Long Term Evolution）通信を用いて行うものとする。

図１に示す通信システムでは、インターネット１６上にコアネットワーク１０（１０－１，…，１０－ｍ）が設けられる。コアネットワーク１０には、例えばクラウドサーバ１２、ダイナミックマップサーバ１４、監視対象情報管理サーバ１５が設けられる。クラウドサーバ１２は、各種サービスに対応するサーバである。

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

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

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

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

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

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

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

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

図２には、図１に示す通信システムにおける分散協調セキュリティ分析技術の概略を説明するための図である。
図２に示すように、監視対象情報管理サーバ１５は、監視対象情報１５Ｊとして、ＩｏＴ機器毎の統一的ＩＤをもとに監視対象とするＩｏＴ機器について、サービス、エッジ、セル（基地局）などの在圏状況の対応関係を管理している。監視対象情報管理サーバ１５は、対応関係等を含む監視対象情報を、各エッジＡ，Ｂの異常トラフィック分析装置２８－Ａ，２８－Ｂ（異常トラヒック分析エンジン）に対して同報配信する。基地局間を監視対象車両（ＩｏＴ機器４０）が移動した際には、移動網３３の移動体ネットワーク管理システムにより提示された識別情報および移動先情報（ハンドオーバ情報）を用いて、ＩｏＴ機器４０の移動を検知する。例えば、基地局Ａ範囲から基地局Ｂの範囲へのＩｏＴ機器４０の移動を検知したエッジＡの異常トラフィック分析装置（本実施形態においてはセキュリティエンジン）２８－Ａは、エッジＢの異常トラフィック分析装置（本実施例形態においてはセキュリティエンジン）２８－Ｂに対して、異常トラヒック分析に必要な情報をエッジＢへ送付する。従って、異常トラフィック分析装置２８－Ｂは、基地局Ｂ範囲に移動してきたＩｏＴ機器４０からのトラヒックに対して、異常トラフィック分析装置２８－Ａから受信した情報を用いて高精度の異常トラフィックの検知を実行できるようになる。

本実施形態における通信システムでは、各エッジに配置された異常トラフィック分析装置２８にセキュリティエンジンの間で情報連携するための機能（後述する分散協調管理部）が設けられ、この機能により複数のエッジに分散配置された異常トラフィック分析装置２８が連携して、監視対象とするＩｏＴ機器の移動に追随した、情報交換と連続監視を実現する。

図３は、セルとエッジとサービスの関係の一例を示す図である。
セルとエッジとサービスの関係を示すデータは、ＩｏＴ機器４０の移動に伴うハンドオーバにより在圏するセルが変わるとき、エッジが変わるかどうかを判断するために使用される。

エッジは、１つ以上のサービスを提供するが、全てのエッジが同じサービスを提供するとは限らない。また、サービスのうち２つは、例えば、プローブ情報収集とＬＤＭ（Locl Dynamic Map）配信である。セルは、エッジに所属するが、サービスによって所属が変わる場合がある。セルとサービスのペアによって所属するエッジは一意に決定する。

図３に示す例では、サービス１において、セル２とセル３との間の移動ではエッジの移動は発生しないが、セル３とセル４との間の移動ではエッジの移動が発生する。一方、サービス２においては、セル２とセル３との間の移動でエッジの移動が発生する。

なお、前述したセルとエッジとサービスの関係は、図４のような関係のように表すことができる。図４は、セルとエッジとサービスの関係の他の一例を示す図である。

前述したセルとエッジとサービスの関係を表現可能なデータ構造としては、ディレクトリ(またはツリー)構造が考えられる。図５は、セルとエッジとサービスの関係を表すデータ構造の一例を示す図である。

図５に示すデータ構造を元にしたセル移動時のエッジ移動判定方法（１）～（４）を以下に示す。
（１）ハンドオーバ情報通知（後述する）により、ＩｏＴ機器４０に搭載されたＬＴＥ通信回線の固有の識別子であるＩＭＳＩ（International Mobile Subscriber Identity）および切り替え先セル識別子（ｃ２）を取得する。

（２）監視対象情報管理サーバ１５において管理された監視対象情報をもとに、ＩＭＳＩに対応するＵＥ識別子の在圏中セル識別子（ｃ１）を取得する（在圏中セル識別子（ｃ１）と切り替え先セル識別子（ｃ２）は必ずしも連続しない)。

（３）サービス単位で在圏中セル識別子（ｃ１）と切り替え先セル識別子（ｃ２）を検索し、それぞれのセルが所属するエッジ識別子（ｅ１，ｅ２）を取得する。

（４）全てのサービスについて、（３）を実施する。

図６は、セルとエッジとサービスの関係を示すエッジサービスセル対応情報（管理データ）の一例を示す図である。なお、同一サービス内に同一のエッジが存在しない、及び異なるサービス下の同一のエッジで同一名称のセルが存在しないものとし、データ整合性が維持されるものとする。

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

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

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

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

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

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

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

トラヒック受信解析部Ｍ１は、ゲートウェイ２７に送受信されるトラヒックと同じトラヒック（ミラーリングトラヒック）を受信する。トラヒック受信解析部Ｍ１は、トラヒックデータの記録、トラヒック（ヘッダ部及びペイロード部）についての解析、エントリデータの生成等を実行する。

分析方法決定部Ｍ２は、トラヒックの異常を検出するための分析アルゴリズム、及び分析アルゴリズムに従う分析に使用されるパラメータを決定する。

分析部Ｍ３は、分析方法決定部Ｍ２によって決定された分析アルゴリズム及びパラメータに応じてトラヒックに対する分析を実行する。

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

分散協調管理部Ｍ５は、監視対象情報管理サーバ１５からの監視対象情報の受信、移動体ネットワーク管理システム（管理サーバ１７）からのハンドオーバ情報通知メッセージの受信、通知メッセージに応じたＩｏＴ機器のセル移動前後でのエッジの移動判定等を実行する。

次に、本実施形態の通信システムにおける異常トラフィックの検出のための動作について説明する。
図９は、異常トラフィック分析装置２８（異常トラフィック検知エンジン５０）の処理の流れを示す図である。

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

（２）トラヒック受信解析部Ｍ１は、トラヒックに対して構文解析して、分析対象のパケットの選別、ＩＰ（internet protocol）パケットヘッダにある５ｔｕｐｐｌｅ情報（送信元アドレス、宛先アドレス、送信元ポート番号、宛先ポート番号、プロトコル情報）等の共通情報と、ペイロード情報等を取得し、エントリデータＤ１を生成する。トラヒック受信解析部Ｍ１は、エントリデータＤ１を分析方法決定部Ｍ２へ引渡す。

（３）分析方法決定部Ｍ２は、受け取ったエントリデータＤ１をもとに、後述する分析次数決定ルールにより次に実行すべき分析方法を決定し、決定された分析の次数を付加したエントリデータＤ１を分析部Ｍ３へ引渡す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、移動体ネットワーク管理システムからＩｏＴ機器（ＵＥ）のハンドオーバ情報通知メッセージを受信した際の動作について説明する。
図１０（Ａ）は、ハンドオーバ情報通知メッセージ受信時の移動元側の異常トラフィック分析装置２８（異常トラフィック検知エンジン５０）の処理、図１０（Ｂ）は、移動先側の異常トラフィック分析装置２８（異常トラフィック検知エンジン５０）の処理の流れをそれぞれ示す図である。

図１１は、移動元側／移動先側の異常トラフィック分析装置２８（分散協調管理部Ｍ５）による分散協調の処理を示すフローチャート、図１２は、分散協調管理部Ｍ５の動作を示すフローチャートである。

（１）移動元の異常トラフィック分析装置２８の分散協調管理部Ｍ５は、監視対象情報管理サーバ１５からハンドオーバ情報通知メッセージ（ハンドオーバ契機）を受信すると（図１２、ステップＳ２１）、ハンドオーバ情報通知処理を実行する（ステップＳ２２）。なお、分散協調管理部Ｍ５は、移動網３３（モバイルネットワーク）の管理サーバ１７からのハンドオーバ契機のメッセージを、監視対象情報管理サーバ１５を通じて受信しているが、他の方法によりハンドオーバ契機を取得しても良い。例えば、個々のＩｏＴ機器４０が搭載された車両の移動状況からハンドオーバ契機（エッジ間移動）を推定するなどしても良い。

まず、分散協調管理部Ｍ５は、メッセージの通知理由を判別する（ステップＳ３１）。メッセージの通知理由がハンドオーバの要求である場合、分散協調管理部Ｍ５は、メッセージから移動先のセル情報（セルＩＤ）と、ＵＥ情報データベースＤＢ４のＵＥ情報により管理中のＩｏＴ機器（ＵＥ）の在圏セルを示す情報を取得する。

（２）分散協調管理部Ｍ５は、更に、ＵＥ情報により管理しているエッジ、サービス、セル対応情報を照会し、移動前のセルと移動後のセルでエッジの移動が発生するか否かを判定する（ステップＳ３２）。

（３）エッジの移動が発生しない場合（ステップＳ３３、Ｎｏ）、分散協調管理部Ｍ５は、後続する処理がなくループする（ステップＳ３６）。一方、エッジの移動が発生する場合（ステップＳ３３、Ｙｅｓ）、分散協調管理部Ｍ５は、移動前後のエッジ識別子をもとに異常トラヒック分析エンジンのアドレスを取得する（ステップＳ３４）。また、分散協調管理部Ｍ５は、トラヒック受信解析部Ｍ１に、エッジ移動の旨を、当該ＩｏＴ機器（ＥＵ）と移動先エッジの情報と共に通知する。

（４）トラヒック受信解析部Ｍ１は、当該ＩｏＴ機器（ＥＵ）のエントリデータ、ＵＥ別脅威レベル情報、トラヒックデータを、予め設定された特定の条件に基づいて抽出し、移動先のエッジに配置された異常トラフィック分析装置２８（異常トラヒック分析エンジン）のトラヒック受信解析部Ｍ１に、分散協調情報として取得したアドレスをもとに通知する（ステップＳ１６，Ｓ３５）。

すなわち、エッジを移動するＩｏＴ機器からのトラヒックについて、異常トラフィックの分析を継続して実行するために必要な分析継続情報を、移動先のエッジの異常トラフィック分析装置２８に渡す。本実施形態においては、分散協調管理部Ｍ５を介して渡す。ここでは、分析中の脅威レベルや分析途中のトラヒックデータについても、移動先の異常トラフィック分析装置２８に渡す。これにより、ＩｏＴ機器がエッジを移動しても、このＩｏＴ機器に対して途切れのないシームレスな分析を可能にする。

図１１には、ハンドオーバ要求メッセージを受信した場合（ステップＳ１１）の分散協調情報の生成を示している（ステップＳ１２～Ｓ１６）。

トラヒック受信解析部Ｍ１は、エントリデータベースＤＢ５から当該ＩｏＴ機器の分析に必要なエントリデータを抽出する（ステップＳ１２）。ここでは、予め設定された条件で定めたデータ範囲分のエントリデータに限定して抽出する。例えば、トラヒック受信解析部Ｍ１は、分析に必要なエントリデータの範囲を、分析対象とするデータの包含関係から算出して抽出する。例えば、ある分析が過去３０秒分のエントリデータを用いた時系列分析を行い、ある分析は、前述した過去３０秒分のエントリデータを含む過去１０分のエントリデータを用いた時系列分析を行う場合、包含関係から、過去１０分のエントリデータの範囲を分析対象とする。また、時間の包含関係だけでなく、位置関係などの他の包含関係に基づいて、分析に必要なエントリデータの範囲を抽出することも可能である。

また、トラヒック受信解析部Ｍ１は、ＵＥ別脅威レベルデータベースＤＢ２から対象とするＩｏＴ機器の脅威レベルを抽出する（ステップＳ１４）。また、ＵＥ別脅威レベルデータベースＤＢ２に登録されたＩｏＴ機器を特定する情報、例えばＩＰアドレスを通信元のエッジのＩＰアドレスに変更する。この際、渡されたデータであることを示すフラグをつけることで、分析の際に、具体的にどのエッジへの攻撃であったかも分析時に確認することができる。（ステップＳ１５）。

なお、トラヒック受信解析部Ｍ１は、現在のＩｏＴ機器に対する脅威レベル（過去の分析結果により算出）に基づいて、分散協調情報を移動先エッジの異常トラフィック分析装置２８に送信するか否かを判断するようにしても良い。例えば、脅威レベルが予め設定されたレベルより高い場合など、診断が確定している状況では、移動先のエッジにおいて継続して分析する必要がない。こうした場合、分散協調情報を送信する必要ないと判断することができる。

こうして、分析に必要なエントリデータの範囲を限定する、あるいは脅威レベルをもとに分散協調情報を送信しないと判断することで、異なるエッジの異常トラフィック分析装置２８の間のトラヒック量の増大を抑えることができる。これにより、ネットワークを効率的に利用することが可能となる。

（５）移動先エッジに配置された異常トラフィック分析装置２８のトラヒック受信解析部Ｍ１は、分散協調情報からエントリデータ、トラヒックデータ、及びＵＥ別脅威情報を受信し（ステップＳ１７）、それぞれエントリデータベースＤＢ５、トラヒックデータデータベースＤＢ１、及びＵＥ別脅威レベルデータベースＤＢ２に記憶させる（ステップＳ１８，Ｓ１９）。

なお、異常トラフィック分析装置２８の間の分散協調情報の送信は、ハンドオーバ完了通知が受信されるまで、あるいは予め設定された一時期間において継続して実行されるものとする（ステップＳ１３ａ～Ｓ１３ｂ）。これにより、ＩｏＴ機器のエッジ間の移動に伴い、継続した分析に必要なデータの欠損が生じないようにすることができる。

移動元のエッジの分散協調管理部Ｍ５は、ハンドオーバ完了通知が受信されると（ステップＳ３１）、ＵＥ情報データベースＤＢ４のＵＥ情報の在圏中セル識別子を、メッセージにより取得したセル識別子により更新する（ステップＳ３７）。

このようにして、本実施形態における通信システムでは、各エッジに配置された異常トラフィック分析装置２８のエンジン間情報連携機能が連携して、移動先のエッジにおいても対象とするＩｏＴ機器についての分析に必要なデータを含む分散協調情報を、移動先のエッジの異常トラフィック分析装置２８から送信するので、ＩｏＴ機器がエッジ間を移動しても適切に情報連携してシームレスな分析が可能となる。

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

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

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

Claims (5)

1. 機器からのトラヒックを受信する受信手段と、
   前記機器からのトラヒックが異常トラヒックであるかを、異常の詳細度の再設定を繰り返しながら分析して、脅威レベルを判定する分析手段と、
   前記分析手段による分析結果を記録させる分析結果記録手段と、
   前記機器のエッジ間の移動を管理する機器管理手段とを有し、
   前記機器管理手段により前記分析手段により分析の対象としている機器が他のエッジへ移動することが判定される場合に、
   前記受信手段は、前記機器からのトラヒックについて、前記機器からのトラヒックに応じたトラヒックデータ、過去に受信した情報の発信元と過去に受信した情報の脅威レベルとが対応付けられたエントリデータ、及び前記機器に対応する脅威レベルを示すデータの何れかをもとに分析を継続するための情報を生成して、
   前記機器に対応する脅威レベルをもとに、分析を継続するための情報を送信するか否かを判断し、
   この判断結果に基づいて、前記機器の移動先とするエッジに含まれる、トラヒックを分析する装置に、分析を継続するための情報を送信する異常トラヒック分析装置。
2. 前記受信手段は、予め設定された条件で定めたデータ範囲分に限定したデータを抽出して、この限定したデータをもとに、分析を継続するための情報を生成する請求項１記載の異常トラヒック分析装置。
3. 前記機器管理手段は、外部サーバにおいて管理された監視対象とする機器の在圏状況の対応関係が記録された監視対象情報を受信し、前記監視対象情報をもとに前記機器のエッジ間の移動を管理する請求項１記載の異常トラヒック分析装置。
4. 機器からのトラヒックを受信する受信工程と、
   前記機器からのトラヒックが異常トラヒックであるかを、異常の詳細度の再設定を繰り返しながら分析して、脅威レベルを判定する分析工程と、
   前記分析工程による分析結果を記録させる分析結果記録工程と、
   前記機器のエッジ間の移動を管理する機器管理工程と、
   前記機器管理工程により前記分析工程により分析の対象としている機器が他のエッジへ移動することが判定される場合に、
   前記機器からのトラヒックについて、前記機器からのトラヒックに応じたトラヒックデータ、過去に受信した情報の発信元と過去に受信した情報の脅威レベルとが対応付けられたエントリデータ、及び前記機器に対応する脅威レベルを示すデータの何れかをもとに分析を継続するための情報を生成して、
   前記機器に対応する脅威レベルをもとに、分析を継続するための情報を送信するか否かを判断し、
   この判断結果に基づいて、前記機器の移動先とするエッジに含まれる、トラヒックを分析する装置に、分析を継続するための情報を送信する工程とを有する異常トラヒック分析方法。
5. 請求項１乃至３の何れかに記載の異常トラヒック分析装置が具備する各手段が行う処理を、当該異常トラヒック分析装置が備えるコンピュータに実行させる異常トラヒック分析プログラム。

Images