特許 7563227 ネットワーク監視制御システム、監視制御装置、解析監視サーバ及びネットワーク監視制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-30

(45)【発行日】2024-10-08

(54)【発明の名称】ネットワーク監視制御システム、監視制御装置、解析監視サーバ及びネットワーク監視制御方法

(51)【国際特許分類】

   H04L 43/04 20220101AFI20241001BHJP

【ＦＩ】

H04L43/04

【請求項の数】 8

(21)【出願番号】P 2021026228

(22)【出願日】2021-02-22

(65)【公開番号】P2022127966

(43)【公開日】2022-09-01

【審査請求日】2023-06-08

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100119677

【弁理士】

【氏名又は名称】岡田 賢治

(74)【代理人】

【識別番号】100160495

【弁理士】

【氏名又は名称】畑 雅明

(74)【代理人】

【識別番号】100115794

【弁理士】

【氏名又は名称】今下 勝博

(72)【発明者】

【氏名】椎名 亮太

(72)【発明者】

【氏名】福井 達也

(72)【発明者】

【氏名】成川 聖

(72)【発明者】

【氏名】南 勝也

(72)【発明者】

【氏名】谷口 友宏

(72)【発明者】

【氏名】猿渡 俊介

(72)【発明者】

【氏名】藤橋 卓也

(72)【発明者】

【氏名】渡邊 尚

【審査官】前田 健人

(56)【参考文献】

【文献】特開２０１７－１４３５８３（ＪＰ，Ａ）

【文献】特開２００８－２４４６４０（ＪＰ，Ａ）

【文献】特開２０１９－１０１７１１（ＪＰ，Ａ）

【文献】特開２００４－３２８３０７（ＪＰ，Ａ）

【文献】特開平０７－０６６８５３（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ４３／００－４３／５５

(57)【特許請求の範囲】

【請求項1】

監視制御装置及び解析監視サーバを備え、
前記監視制御装置は、
通信端末からの通信をミラーリングし、
通信端末ごとに、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換し、
前記ビットマップ構造のデータを前記解析監視サーバに送信し、
通信端末からの通信を遮断するための遮断情報を前記解析監視サーバから受信すると該当する通信端末からの通信を遮断すること、
前記解析監視サーバは、
前記監視制御装置から前記ビットマップ構造のデータを受信し、
受信した前記ビットマップ構造のデータを通信端末ごとに記憶し、
記憶した通信端末の前記ビットマップ構造のデータと前記記憶した通信端末の過去のビットマップ構造のデータとを比較して、異常であると判断したときに、当該通信端末からの通信を遮断するための遮断情報を前記監視制御装置に送信すること、
を特徴とするネットワーク監視制御システム。

【請求項2】

前記監視制御装置は、前記ミラーリングした通信の所定時間内での通信の有無をバイナリで表されるビットマップ構造のデータに変換することを特徴とする請求項１に記載のネットワーク監視制御システム。

【請求項3】

前記監視制御装置は、前記ミラーリングした通信の所定時間内の通信のトラヒック量を予め定めた閾値で閾値判定した結果をバイナリで表されるビットマップ構造のデータに変換することを特徴とする請求項１に記載のネットワーク監視制御システム。

【請求項4】

前記解析監視サーバは、前記記憶した通信端末の前記ビットマップ構造のデータにおける時間当たりのビットの数が、前記記憶した通信端末の過去のビットマップ構造のデータにおける時間当たりのビットの数の最高値よりも多いときに、当該通信端末からの通信が異常であると判断する請求項１から３のいずれかに記載のネットワーク監視制御システム。

【請求項5】

前記解析監視サーバは、前記記憶した通信端末の前記ビットマップ構造のデータにおける時間当たりのビットの数が、前記記憶した通信端末の過去のビットマップ構造のデータにおける時間当たりのビットの数の平均値の所定倍よりも多いときに、当該通信端末からの通信が異常であると判断する請求項１から３のいずれかに記載のネットワーク監視制御システム。

【請求項6】

通信端末からの通信をミラーリングし、
通信端末ごとに、ミラーリングした通信の所定時間内での通信の有無をバイナリで表されるビットマップ構造のデータに変換し、
前記ビットマップ構造のデータを送信し、
通信端末からの通信を遮断するための遮断情報を受信すると該当する通信端末からの通信を遮断することを特徴とする監視制御装置。

【請求項7】

通信端末ごとに、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータを受信し、
受信した前記ビットマップ構造のデータを通信端末ごとに記憶し、
記憶した通信端末の前記ビットマップ構造のデータと前記記憶した通信端末の過去のビットマップ構造のデータとを比較して、異常であると判断したときに、当該通信端末からの通信を遮断するための遮断情報を送信することを特徴とする解析監視サーバ。

【請求項8】

監視制御装置及び解析監視サーバを用いたネットワーク監視制御方法であって、
前記監視制御装置は、
通信端末からの通信をミラーリングし、
通信端末ごとに、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換し、
前記ビットマップ構造のデータを前記解析監視サーバに送信すること、
前記解析監視サーバは、
前記監視制御装置から前記ビットマップ構造のデータを受信し、
受信した前記ビットマップ構造のデータを通信端末ごとに記憶し、
記憶した通信端末の前記ビットマップ構造のデータと前記記憶した通信端末の過去のビットマップ構造のデータとを比較して、異常であると判断したときに、当該通信端末からの通信を遮断するための遮断情報を前記監視制御装置に送信し、
前記監視制御装置は、
前記解析監視サーバから前記遮断情報を受信すると該当する通信端末からの通信を遮断すること
を特徴とするネットワーク監視制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ＩｏＴ対応のネットワークにおいて、ネットワークの安全性を確保するセキュリティ技術に関する。

【背景技術】

【0002】

センサ等のＩｏＴデバイスが広く普及し、多様な産業に応用されている。ＩｏＴデバイスにおける課題の一つが、セキュリティ対策である。ＩｏＴデバイスはセキュリティの甘さから、サイバー攻撃の対象になりやすく、世界的にもＩｏＴデバイスを狙ったサイバー攻撃が年々増加の傾向にある。

【0003】

２０１６年には、「Ｍｉｒａｉ」というマルウェアによるサイバー攻撃が発生した。サイバー攻撃の状況を図１に示す。図１において、５０はＩｏＴデバイス、５１はネットワーク、７０は攻撃対象である。正常時は、ＩｏＴデバイス５０は、ネットワーク５１を介してＩｏＴサーバ５２にセンシング情報等を送信する。

【0004】

ＩｏＴデバイス５０が攻撃者によってマルウェアに感染すると、Ｃ＆Ｃ（コマンド＆コントロール）サーバ（不図示）からボットをダウンロードし、次の感染先を探すという挙動にでる。ボットはＣ＆Ｃサーバからの指示を待ち、感染したＩｏＴデバイス５０が、例えば、ネットワーク５１を介して、ＨＴＴＰリクエストやＵＤＰパケットを攻撃対象７０に大量に送りつけるようなＤＤｏＳ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ：分散型サービス妨害）攻撃などのＤｏＳ攻撃に加担してしまう。感染したＩｏＴデバイス５０の数が大量になると、攻撃対象７０となったサイトのサービスは簡単にダウンしてしまう。

【0005】

このようなサイバー攻撃を防御するために、ホワイトリストを用いたＩｏＴデバイス対応のセキュリティシステムが提案されている（例えば、非特許文献１参照。）。このセキュリティシステムでは、通信端末のＩＰアドレスやＭａｃアドレスを利用して接続を許容する接続先のリストであるホワイトリストをＩｏＴゲートウェイに備える。

【0006】

ＩｏＴゲートウェイは、ＩｏＴデバイスとＩｏＴサーバとの間に設置され、ＩｏＴデバイスとＩｏＴサーバとの間の通信を常時監視する。監視中には、外部のデバイスからのアクセスや新たなデバイスからのアクセスを検知し、ホワイトリストに記載されていないデバイスからの通信を遮断する。

【0007】

しかし、ＩｏＴゲートウェイは、通信端末のＩＰアドレスやＭａｃアドレスを基にした通信分析を行うため、ＩｏＴゲートウェイに多くのコンピューティングリソースを配備する必要がある。必然的に高性能なＩｏＴゲートウェイが要求される。また、ＩｏＴサーバとＩｏＴデバイスとの間の通信データの通信に対して、ＩｏＴサーバとＩｏＴデバイスとの間との間に同一トラヒック量の制御用の通信が新たに発生する。このため、ネットワークへの負荷が過大となる問題があった。

【先行技術文献】

【非特許文献】

【0008】

【文献】野村公輝、永渕幸雄、谷川真樹、「ＩｏＴ－ＧＷ向けホワイトリストの機械学習期間における暫定的なホワイトリストの提供手法の提案」、情報処理学会第８０回全国大会講演論文集、２Ｅ－０３、ｐｐ．３－４４９～３－４５０、２０１８年３月

【発明の概要】

【発明が解決しようとする課題】

【0009】

本開示は、上記事情に着目してなされたもので、本開示のネットワーク監視制御システム及びネットワーク監視制御方法は、通信端末のトラヒック量の監視制御に必要なコンピューティングリソースを低減し、ネットワークへの負荷を軽減することを目的とする。

【0010】

本開示の監視制御装置は、通信端末のトラヒック量の監視制御に必要なコンピューティングリソースを低減し、ネットワークへの負荷を軽減することを目的とする。

【0011】

本開示の解析監視サーバは、通信端末のトラヒック量の監視制御に必要なコンピューティングリソースを低減することを目的とする。

【課題を解決するための手段】

【0012】

本開示のネットワーク監視制御システムは、
監視制御装置及び解析監視サーバを備え、
前記監視制御装置は、
通信端末からの通信をミラーリングし、
通信端末ごとに、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換し、
前記ビットマップ構造のデータを前記解析監視サーバに送信し、
通信端末からの通信を遮断するための遮断情報を前記解析監視サーバから受信すると該当する通信端末からの通信を遮断すること、
前記解析監視サーバは、
前記監視制御装置から前記ビットマップ構造のデータを受信し、
受信した前記ビットマップ構造のデータを通信端末ごとに記憶し、
記憶した通信端末の前記ビットマップ構造のデータと前記記憶した通信端末の過去のビットマップ構造のデータとを比較して、異常であると判断したときに、当該通信端末からの通信を遮断するための遮断情報を前記監視制御装置に送信すること、
を特徴とする。

【0013】

本開示の監視制御装置は、
通信端末からの通信をミラーリングし、
通信端末ごとに、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換し、
前記ビットマップ構造のデータを送信し、
通信端末からの通信を遮断するための遮断情報を受信すると該当する通信端末からの通信を遮断することを特徴とする。

【0014】

本開示の解析監視サーバは、
通信端末ごとに、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータを受信し、
受信した前記ビットマップ構造のデータを通信端末ごとに記憶し、
記憶した通信端末の前記ビットマップ構造のデータと前記記憶した通信端末の過去のビットマップ構造のデータとを比較して、異常であると判断したときに、当該通信端末からの通信を遮断するための遮断情報を送信することを特徴とする。

【0015】

本開示のネットワーク監視制御方法は、
監視制御装置及び解析監視サーバを用いたネットワーク監視制御方法であって、
前記監視制御装置は、
通信端末からの通信をミラーリングし、
通信端末ごとに、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換し、
前記ビットマップ構造のデータを前記解析監視サーバに送信し、
前記解析監視サーバは、
前記監視制御装置から前記ビットマップ構造のデータを受信し、
受信した前記ビットマップ構造のデータを通信端末ごとに記憶し、
記憶した通信端末の前記ビットマップ構造のデータと前記記憶した通信端末の過去のビットマップ構造のデータとを比較して、異常であると判断したときに、当該通信端末からの通信を遮断するための遮断情報を前記監視制御装置に送信し、
前記監視制御装置は、
前記解析監視サーバから前記遮断情報を受信すると該当する通信端末からの通信を遮断すること
を特徴とする。

【発明の効果】

【0016】

本開示のネットワーク監視制御システム及びネットワーク監視制御方法は、通信端末のトラヒック量の監視制御に必要なコンピューティングリソースを低減し、ネットワークへの負荷を軽減することができる。

【0017】

本開示の監視制御装置は、通信端末のトラヒック量の監視制御に必要なコンピューティングリソースを低減し、ネットワークへの負荷を軽減することができる。

【0018】

本開示の解析監視サーバは、通信端末のトラヒック量の監視制御に必要なコンピューティングリソースを低減することができる。

【図面の簡単な説明】

【0019】

【図1】従来のネットワークの構成の一例を示す。

【図2】本開示のネットワーク監視制御システムの構成の一例を示す。

【図3】本開示の監視制御装置の構成の一例を示す。

【図4】本開示の監視制御装置の動作の一例を示す。

【発明を実施するための形態】

【0020】

以下、本開示の実施形態について、図面を参照しながら詳細に説明する。なお、本開示は、以下に示す実施形態に限定されるものではない。これらの実施の例は例示に過ぎず、本開示は当業者の知識に基づいて種々の変更、改良を施した形態で実施することができる。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

【0021】

本実施形態のネットワーク監視制御システムの構成の一例を図２に示す。図２において、１０は監視制御装置、２０は解析監視サーバ、５０は通信端末としてのＩｏＴデバイス、５１はネットワーク、５２はＩｏＴサーバである。複数のＩｏＴデバイス５０がネットワーク５１を介してＩｏＴサーバ５２に接続されている。ＩｏＴデバイス５０が例えば、センサデバイスの場合、ＩｏＴデバイス５０は収集したセンシング情報を、ネットワーク５１を介してＩｏＴサーバ５２に送信する。ＩｏＴサーバ５２は収集したセンシング情報をデータ処理する。

【0022】

本実施形態のネットワーク監視制御システムでは、ＩｏＴデバイス５０とネットワーク５１との間に監視制御装置１０を備え、監視制御装置１０にネットワーク経由で接続される解析監視サーバ２０を備える。監視制御装置１０及び解析監視サーバ２０が連動して、ＩｏＴデバイス５０を監視制御する。

【0023】

監視制御装置１０は複数のＩｏＴデバイス５０を収容してもよい。監視制御装置１０は、ＩｏＴデバイス５０からの通信をミラーリングし、ミラーリングした通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換し、ＩｏＴデバイスごとのビットマップ構造のデータを解析監視サーバ２０に送信する。監視制御装置１０から解析監視サーバ２０への送信は、ＩｏＴデバイス５０への送信と同じネットワーク経由でもよく、異なるネットワーク経由でもよい。

【0024】

監視制御装置１０は、ＩｏＴデバイス５０からの通信そのものを複製して送信することなく、通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換して送信するため、ネットワークの負荷を軽減することができる。また、バイナリで表されるビットマップ構造のデータは解析監視サーバ２０のコンピューティングリソースを低減することができる。

【0025】

解析監視サーバ２０は複数の監視制御装置１０からＩｏＴデバイスごとのビットマップ構造のデータを受信し、記憶する。解析監視サーバ２０は、ＩｏＴデバイスごとのビットマップ構造のデータを長期間にわたって記憶している。ＩｏＴデバイスごとに、記憶したビットマップ構造のデータを過去のデータと比較して、新たに記憶したＩｏＴデバイスのビットマップ構造のデータが異常であると判断すると、そのＩｏＴデバイスの通信を遮断するための遮断情報を監視制御装置１０に送信する。

【0026】

記憶したビットマップ構造のデータを過去のデータと比較して、新たに記憶したＩｏＴデバイスのビットマップ構造のデータが異常であると判断する例として、記憶した通信端末のビットマップ構造のデータにおける時間当たりのビットの数が、記憶した通信端末の過去のビットマップ構造のデータにおける時間当たりのビットの数の最高値よりも多いときに、当該通信端末からの通信が異常であると判断することが挙げられる。

【0027】

時間当たりのビットの数が、過去の最高値よりも多ければ、ＩｏＴデバイスからのトラヒック量が異常である可能性が高いからである。

【0028】

他の例として、記憶した通信端末のビットマップ構造のデータにおける時間当たりのビットの数が、記憶した通信端末の過去のビットマップ構造のデータにおける時間当たりのビットの数の平均値の所定倍よりも多いときに、当該通信端末からの通信が異常であると判断することが挙げられる。

【0029】

時間当たりのビットの数が、過去の平均値の所定倍よりも多ければ、ＩｏＴデバイスからのトラヒック量が異常である可能性が高いからである。所定倍は予め任意の値を設定しておけばよい。

【0030】

例えば、１時間当たりのビットの数が過去の最高値又は時間当たりのビットの数の平均値の所定倍よりも多いときは、当該通信端末からの通信が異常であると判断する。１時間当たりのビットの数だけでなく、１か月当たりのビットの数、１週間当たりのビットの数、１日当たりのビットの数等でもよい。単位時間を短くすると即応できるが、エラーも発生し易くなる。平均値の所定倍としては、平均値の２倍以上や１０倍以上が例示できる。

【0031】

これらの判断方法は、解析も容易であるため、解析監視サーバ２０は高度な処理をすることなく、容易に判断することができる。

【0032】

解析監視サーバ２０は、複数の監視制御装置１０からのビットマップ構造のデータを集中処理するため、監視制御装置１０の負担が軽減される。また、通信の異常を解析する際に、通信自体を解析するのではなく、ビットマップ構造のデータを解析するため、高度な処理は不要となる。その結果、解析に必要なコンピューティングリソースを低減することができる。

【0033】

解析監視サーバ２０からの遮断情報を受信した監視制御装置１０は、該当するＩｏＴデバイス５０からの通信を遮断する。その結果、攻撃対象へのＤＤｏＳ攻撃等を防止することができる。

【0034】

監視制御装置１０の構成を図３に示す。１０は監視制御装置、１１は監視部、１２は収集部、１３は解析変換部、１４は通信部、１５は制御部である。監視部１１は、通信端末としてのＩｏＴデバイス（不図示）からＩｏＴサーバ（不図示）への通信を透過的に扱う。同時に、その通信をミラーリングし、収集部１２にミラーリング信号として出力する。収集部１２は、監視部１１からのミラーリング信号を一部記録しつつ、定期的に解析変換部１３へとミラーリング信号を出力する。解析変換部１３は、ミラーリング信号のトラヒック量を分析して、バイナリで表されるビットマップ構造のデータに変換する。ビットマップ構造のデータはミラーリング信号に比較して、大幅にデータ量が軽減されている。

【0035】

解析変換部１３が変換するビットマップ構造のデータの例として、ミラーリングした通信の所定時間内での通信の有無をバイナリで表されるビットマップ構造のデータが挙げられる。例えば、所定時間内で通信があれば「１」とし、通信がなければ「０」とする。通信の有無で単純にバイナリ表現するため、コンピュータリソースを低減することができる。

【0036】

他の例として、ミラーリングした通信の所定時間内のトラヒック量を予め定めた閾値で閾値判定した結果をバイナリで表されるビットマップ構造のデータが挙げられる。例えば、通信の所定時間内のトラヒック量を予め定めた閾値で閾値判定し、超えていれば「１」とし、超えていなければ「０」とする。通信のトラヒック量を予め定めた閾値で閾値判定した結果をバイナリ表現するため、コンピュータリソースを低減することができる。また、所定値を設定変更すれば、トラヒック量の変動状況に応じて閾値を可変することができる。

【0037】

解析変換部１３は、高度な処理をすることなく、トラヒック量を容易に解析して、ビットマップ構造のデータに変換することができる。

【0038】

解析変換部１３に入力されるミラーリング信号のトラヒック量を、バイナリで表されるビットマップ構造のデータに変換した例を図４に示す。図４において、横軸は１時間単位で０時から２４時まで、曜日単位で月曜日から日曜日まで、月単位で１月から１２月まで、日単位で１日から３６５日までを表している。縦軸はアクセス数の多い宛先ＩＰアドレスを１位から１００位まで順に並べている。

【0039】

ミラーリング信号は、通信信号そのものであるため、膨大なデータ量となる。解析変換部１３は、通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換する。

【0040】

このように、監視制御装置１０は、通信のトラヒック量として、通信の有無又はトラヒック量を予め定めた閾値で閾値判定した結果をバイナリで表されるビットマップ構造のデータに変換するため、通信そのものよりも大幅に情報量を削減することができる。

【0041】

通信部１４は、ビットマップ構造のデータを解析監視サーバに送信する。また、解析監視サーバからの遮断情報を受信する。制御部１５は、通常はＩｏＴデバイス（不図示）からＩｏＴサーバ（不図示）への通信を透過的に扱うよう監視部１１を制御する。通信部１４から遮断情報が入力されると、制御部１５は監視部１１にＩｏＴデバイス（不図示）からの通信を遮断させる。

【0042】

以上説明したように、本開示のネットワーク監視制御システム及びネットワーク監視制御方法は、ＩｏＴデバイス５０からの通信そのものを複製して送信することなく、通信のトラヒック量をバイナリで表されるビットマップ構造のデータに変換して送信し、ビットマップ構造のデータを基にＩｏＴデバイス５０の通信を監視制御する。このため、監視制御装置と解析監視サーバとの間のネットワークへの負荷を軽減して、解析監視サーバのコンピュータリソースを低減しつつ、ＩｏＴデバイス５０が攻撃対象へのＤＤｏＳ攻撃等することを防止することができる。

【0043】

本発明の監視制御装置及び解析監視サーバは、コンピュータとプログラムによっても実現できる。そのプログラムは、記録媒体に記録することも、ネットワークを通して提供することも可能である。

【産業上の利用可能性】

【0044】

本開示は情報通信産業に適用することができる。

【符号の説明】

【0045】

１０：監視制御装置
１１：監視部
１２：収集部
１３：解析変換部
１４：通信部
１５：制御部
２０：解析監視サーバ
５０：ＩｏＴデバイス
５１：ネットワーク
５２：ＩｏＴサーバ

【図1】

【図2】

【図3】

【図4】