(57)【要約】【課題】マルウェア感染を未然に防ぐことに加えて、感染を早期に検出する。【解決手段】監視対象のホストが、ゲートウェイを通じてネットワークに接続され、他のホストとパケット通信を行う構成で適用する。ゲートウェイには全通信を観測するゲートウェイセンサを設け、かつ、監視対象のホストにはＷｅｂサイト閲覧ソフトによる通信を観測するホストセンサを設ける。まず、何もしない場合のアクセス先を抽出し、ホワイトリストを作成する。また、ゲートウェイセンサで、上記ホストによるすべてのアクセス先を抽出し、この抽出からホストセンサによるアクセス先を除いて暫定的ブラックリストを作る。この暫定的ブラックリストからホワイトリストのアクセス先を除外してブラックリストを作成する。ゲートウェイがブラックリストを参照することでマルウェアの行う不正通信を検出し警告を発する。これを、一定時間ごとに行う。【選択図】図１
2014099758.tif 000002
【特許請求の範囲】
【請求項１】
監視対象のホストコンピュータが、ゲートウェイを通じてコンピュータネットワークに接続され、上記コンピュータネットワークを介して他のホストコンピュータとパケット通信を行うネットワーク構成において、
上記ゲートウェイには全通信を観測するゲートウェイセンサを設け、かつ、上記監視対象のホストコンピュータには上記ホストコンピュータ上で動作しＷｅｂサイト閲覧ソフトによる通信を観測するホストセンサを設け、
上記ゲートウェイセンサで、上記ホストコンピュータによるすべてのアクセス先を抽出し、この抽出されたアクセス先から上記ホストセンサによって観測されたアクセス先を除いて暫定的ブラックリストを作成し、
上記暫定的ブラックリストから予め用意されたホワイトリストにあるアクセス先を除外することで、ブラックリストを作成し、
上記ゲートウェイが上記ブラックリストを参照することでマルウェアの行う不正通信を検出し警告を発するものであって、
上記暫定的ブラックリストおよび上記ホワイトリストのアドレス先は、所定のパケット形式に従うものであることを特徴とする、複数センサの観測情報の突合による不正通信検知方法。
【請求項２】
上記暫定的ブラックリストあるいは上記ホワイトリストのアドレス先は、代理手段と同じ変換によって、上記所定のパケット形式に従うアドレスに変換されたものであることを特徴とする請求項１に記載の複数センサの観測情報の突合による不正通信検知方法。
【請求項３】
上記暫定的ブラックリストは、上記監視対象のホストコンピュータ以外のホストコンピュータが接続されたゲートウェイに設けられたゲートウェイセンサによって抽出されたアクセス先あるいは予め用意されたアクセス先も含むことを特徴とする請求項１あるいは２のいずれかに記載の複数センサの観測情報の突合による不正通信検知方法。
【請求項４】
上記暫定的ブラックリストの作成あるいは上記ブラックリストの作成は、直接的にあるいは間接的に上記コンピュータネットワークに接続された処理部で処理されることを特徴とする請求項１から３にいずれか１つに記載の複数センサの観測情報の突合による不正通信検知方法。
【請求項５】
上記処理部は、上記ゲートウェイに接続されたものであることを特徴とする請求項４に記載の複数センサの観測情報の突合による不正通信検知方法。
【請求項６】
上記ブラックリストは、スパムメールデータ、レピュテーションデータ、マルウェア動的解析データ、ダークネット観測データあるいは悪性Ｗｅｂサイトデータを含むデータを含むものであることを特徴とする請求項１から５のいずれか１つに記載の複数センサの観測情報の突合による不正通信検知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数地点のセンサによる観測情報を組み合わせたマルチモーダル分析によって感染後のマルウェアが行う不正通信を検出する複数センサの観測情報の突合による不正通信検知方法に関している。
【背景技術】
【０００２】
近年の攻撃手法の高度化に伴い、従来のファイヤウォールやウイルス対策ソフトなどの防御が突破され、組織内のコンピュータがマルウェアに感染する事例が増えている。そのため、マルウェア感染を未然に防ぐことに加えて、感染を早期に検出することが求められている。
【０００３】
マルウェア検出方法として、特許文献１（特開２０１２−８４９９４号公報）が開示されている。これは、次のような方法である。内部ネットワークの内部端末と他の内部端末との間に既定された通常内部通信、及び、内部端末と外部ネットワークに接続する外部端末との間に既定された通常外部通信を予め記憶装置に記憶する。ネットワーク接続装置から、内部端末の通信情報を取得して、通常内部通信および通常外部通信を参照して、通信情報から、内部端末と他の内部端末との間に既定されない異常内部通信、及び、内部端末と外部端末との間に既定されない異常外部通信とを取得して記憶装置に記憶する。記憶した異常外部通信を所定期間内に行った回数に基いて、内部端末が不審端末であることを検知する。不審端末と他の不審端末との間の、記憶した異常内部通信が所定期間内に発生した回数に基いて、内部ネットワーク内にマルウェアに感染した内部端末が存在すると検知する。
【０００４】
また、特許文献２（特開２００９−１１０２７０号公報）には、マルウエア検出装置が開示されている。これは、監視対象ノード群の中から、共通する第１の宛先へ接続要求情報を送信した複数のノードを検出する第１検出手段と、前記監視対象ノード群の中の各ノードが接続要求情報を送信した第２の宛先の数を検出する第２検出手段と、前記第１検出手段によって検出された複数のノードと前記第２検出手段によって検出された第２の宛先の数とに基づいて、マルウエアに感染したノードを特定する特定手段と、前記特定手段によって特定された特定結果を出力する出力手段と、を備えるものである。
【０００５】
従来のセキュリティ対策では、ファイヤウォールやＩＤＳ（Intrusion Detection System：侵入検知システム）、ウイルス対策ソフトなどによってマルウェアの侵入段階で検出・阻止する対策手法に重点が置かれてきた。しかし、ドライブ・バイ・ダウンロード（Drive-by-Download）攻撃や標的型攻撃などに代表されるように、年々攻撃手法が高度化していく中で、それらの防御が突破され、マルウェアに感染してしまう事例が増加している。そのため、従来からの対策手法に加えて、マルウェアに感染してしまった際に感染の事実を早期に検出可能な手法の確立が希求されている。
【０００６】
マルウェアの多くは攻撃者とのやり取りのためのインターネットアクセスが必須となっているため、その通信を検知することができれば感染ホストコンピュータの特定や駆除等の対策が可能になる。従来の検知技術としては下記のような技術が存在する。
a.  通常使われないポートへのアクセスやプロトコルによるアクセスの検知
b.  既知の悪性ホストコンピュータへのアクセスの検知(ブラックリスト的アプローチ）
c.  既知の正規ホストコンピュータ以外へのアクセスの検知(ホワイトリスト的アプローチ）
d.  マルウェア特有の通信の特徴による検知
【０００７】
ネットワークベースのマルウェア検知手法としては、非特許文献４、８などのものが知られている。これらの文献に記載された検知手法の利点として、各々のホストコンピュータ上に検知機構を導入する必要が無いことから多数のホストコンピュータへの適用が容易な点や、ホストコンピュータ上でのオーバーヘッドが発生しない点が挙げられる。しかし一方で、マルウェアがＣ＆Ｃ（Command and Control）通信などの暗号化通信を用いる場合への対応などの課題が、存在する。
【０００８】
また、アクセス先ベースの検知手法も多く知られている。例えば、グーグル（Ｇｏｏｇｌｅ）セーフブラウジング（非特許文献１１）などのブラックリスト方式では、事前の調査等で判明したマルウェア配布サーバ、Drive-by-Download攻撃サイト、あるいはＣ＆Ｃサーバなどの悪性ホストコンピュータをリスト化しておき、当該ホストコンピュータへの通信を検知する。逆に、正規サイトをホワイトリスト化する場合にも、ホストコンピュータ名のＤＮＳ（Domain Name Server）登録情報やＤＮＳ名前解決のトラフィックなどの様々な特徴を基に悪性ホストコンピュータを判定する手法（非特許文献１、２、３）なども知られている。
【０００９】
ホストコンピュータベースの検知手法としては非特許文献５または６などに記載のものが知られている。これらの手法では、ホストコンピュータ上で動作する各プロセスの挙動を監視できるなど、ネットワークベースの検知手法と比較してより多くの情報が活用できるという利点がある。しかし、ＡＰＩフックやテイント解析などによってプロセスを監視する場合、処理のオーバーヘッドの課題がある。
【００１０】
また、ホストコンピュータ上とネットワーク上のそれぞれで収集した情報を組み合わせた検知手法も知られている（非特許文献７、９）。これらの検知手法では、ホストコンピュータ上で収集した情報（ファイルアクセスやレジストリアクセス、ネットワークアクセスなど）とネットワーク上で収集したトラフィック情報などから特徴量を抽出し、機械学習を用いて検知を行っている。 
【００１１】
ホワイトリスト方式ではリストに登録されていないアクセス先への通信を確実に検出できるが、他方では、正規のアクセス先を全てリスト化するのは困難であり、リスト漏れによる誤検知の結果としてユーザビリティが大きく低下する懸念がある。
【００１２】
一般に、このホワイトリスト作成の困難性は、ユーザのウェブ（Web）ブラウザジングのアクセス先の多様性に大きく起因している。その多様性による影響を取り除くことができれば、効果的な検出が可能になることも考えられる。 
【００１３】
そこで本発明では、複数地点のセンサによる観測情報を組み合わせたマルチモーダル分析によって感染後のマルウェアが行う不正通信を検出する手法を提案する。このマルチモーダル分析は、非特許文献１０の記載に沿うものである。
【００１４】
本発明の利点として以下の点が挙げられる。 
（１）ユーザのウェブブラウジングのアクセス先の多様性の影響を除外することでホワイトリスト作成の困難さを軽減し、リスト漏れによる誤検知（ユーザビリティの低下）を抑えつつ高い検知率を実現できる。
（２）アクセス先情報の観測・突合のみを行う手法というは、ペイロードの検査やホストコンピュータ上での各プロセスによるリソース（ファイルやレジストリなど）へのアクセスを監視する手法よりもシンプルであり、検知おけるオーバーヘッドを抑えられる。
（３）全通信を観測するゲートウェイセンサをネットワーク上に設置して観測を行うことで、各ホストコンピュータ上で観測するよりも、マルウェアを検知し易くなり、マルウェアが観測をくぐり抜けづらくなる。また、ゲートウェイセンサで一括観測することで、その観測結果と、ダークネットやハニーポット、スパムメール、あるいは動的解析などで観測された悪性ホストコンピュータ情報や、レピュテーションデータベースの評価情報などの他の情報との突合が容易となる。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２０１２−８４９９４号公報
【特許文献２】特開２００９−１１０２７０号公報
【非特許文献】
【００１６】
【非特許文献１】M. Antonakakis, R. Perdisci, D. Dagon, W. Lee, and N. Feamster, “Building a Dynamic Reputation System for DNS,” In Proceedings of 19th USENIX Security Symposium, 2010.
【非特許文献２】M. Antonakakis, R. Perdisci, W. Lee, N. Vasiloglou II, and D. Dagon, “Detecting Malware Domains at the Upper DNS Hierarchy,” In Proceedings of 20th USENIX Security Symposium, 2011.
【非特許文献３】L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi,“EXPOSURE: Finding Malicious Domains Using Passive DNS Analysis,” In Proceedings of 18th Annual Network and Distributed System Security Symposium (NDSS2011), 2011.
【非特許文献４】G. Gu, P. Porras, V. Yegneswaran, M. Fong, and W. Lee, “BotHunter: Detecting Malware Infection Through IDS-Driven Dialog Correlation,” In Proceedings of 16th USENIX Security Symposium, 2007.
【非特許文献５】C. Kolbitsch, P. M. Comparetti, C. Kruegel, E. Kirda, X. Zhou, X. Wang, “Effective and Efficient Malware Detection at the End Host,” In Proceedings of the 18th Conference on USENIX Security Symposium, 2009.
【非特許文献６】A. Lanzi, D. Balzarotti, C. Kruegel, M. Christodorescu, E. Kirda, “AccessMiner: Using System-Centric Models for Malware Protection,” In Proceedings of the 17th ACM Conference on Computer and Communications Security (CCS2010),2010.
【非特許文献７】S. Shin, Z. Xu, G. Gu, “EFFORT: Efficient and Effective Bot Malware Detection,” In Proceedings of the 31th Annual IEEE Conference on Computer Communications (INFOCOM2012) Mini-Conference, 2012.
【非特許文献８】T.-F. Yen, and M. K. Reiter, “Traffic aggregation for malware detection,” In Proceedings of the 5th international conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA2008), 2008.
【非特許文献９】Y. Zeng, X. Hu, K. G. Shin, “Detection of Botnets Using Combined Host- and Network-Level Information,” In Proceedings of the 2010 IEEE/IFIP International Conference on Dependable Systems and Networks (DSN2010), 2010.
【非特許文献１０】笠間貴弘、中里純二、鈴木未央、衛藤将史、井上大介、中尾康二、秋山満昭、青木一史、岩村誠、八木毅、斉藤典明、針生剛男、“多様なセンサの観測情報を用いたマルチモーダル分析”電子情報通信学会  ２０１２年暗号と情報セキュリティシンポジウム  (SCIS2012)、 2012.
【非特許文献１１】Google Safe Browsing, https://developers.google.com/safe-browsing/   （2012年11月9日15時50分）
【発明の概要】
【発明が解決しようとする課題】
【００１７】
近年の攻撃手法の高度化に伴い、従来のファイヤウォールやウイルス対策ソフトなどの防御が突破され、組織内のコンピュータがマルウェアに感染する事例が増えている。近年のマルウェアは正規通信に見せかけた通信を行うなど、ステルス性を高める工夫がなされている。そのため、宛先ポートやプロトコル、通信の特徴を用いた検知手法は困難になっている。本発明は、マルウェア感染を未然に防ぐことに加えて、感染を早期に検出することを課題とする。
【課題を解決するための手段】
【００１８】
本発明の、複数センサの観測情報の突合による不正通信検知方法は、監視対象のホストコンピュータが、ゲートウェイを通じてコンピュータネットワークに接続され、上記コンピュータネットワークを介して他のホストコンピュータとパケット通信を行うネットワーク構成において適用するものである。上記ゲートウェイには全通信を観測するゲートウェイセンサを設け、かつ、上記監視対象のホストコンピュータには上記ホストコンピュータ上で動作しＷｅｂサイト閲覧ソフトによる通信を観測するホストセンサを設ける。上記ホストセンサで、あらかじめ決められた条件のもとでのアクセス先を抽出し、この抽出されたアクセス先によってホワイトリストを作成する。あるいは、ホワイトリストには、予め用意したものを用いる。また、上記ゲートウェイセンサで、上記ホストコンピュータによるすべてのアクセス先を抽出し、この抽出されたアクセス先から上記ホストセンサによって観測されたアクセス先を除いて暫定的ブラックリストを作成する。上記暫定的ブラックリストから上記ホワイトリストにあるアクセス先を除外することで、ブラックリストを作成する。上記ゲートウェイが上記ブラックリストを参照することでマルウェアの行う不正通信を検出し警告を発するものである。以上の操作を、例えば、必要に応じて一定時間ごとに行う、あるいは、他の制御手段による要求に沿って行なってもよい。ここで、当然のことながら、上記暫定的ブラックリストおよび上記ホワイトリストのアドレス先は、突合処理を行う都合上、所定のパケット形式に従うものである。また、上記ホワイトリストの代わりに、予め容易され信頼のおけるホワイトリストを用いることもできる。
【００１９】
また、上記監視対象のホストコンピュータがウェブプロキシを経由する場合、上記暫定的ブラックリストあるいは上記ホワイトリストのアドレス先は、代理手段（つまり上記ウェブプロキシ）と同じ変換によって、上記所定のパケット形式に従うアドレスに変換されたものである。
【００２０】
上記暫定的ブラックリストは、上記監視対象のホストコンピュータ以外のホストコンピュータが接続されたゲートウェイに設けられたゲートウェイセンサによって抽出されたアクセス先あるいは予め用意されたアクセス先も含むようにしてもよい。同様に、予め容易され信頼のおけるブラックリストを用いることもできる。
【００２１】
上記暫定的ブラックリストの作成あるいは上記ブラックリストの作成は、直接的にあるいは間接的に上記コンピュータネットワークに接続された処理部で処理される。
【００２２】
特に、上記処理部は、上記ゲートウェイに接続されたものであることが望ましい。
【００２３】
上記ブラックリストは、スパムメールデータ、レピュテーションデータ、マルウェア動的解析データ、ダークネット観測データあるいは悪性Ｗｅｂサイトデータを含むデータを含むものである。ＤＢ（データベース）を用いる場合は、ブラックリストＤＢは、スパムメールＤＢ、レピュテーションＤＢ、マルウェア動的解析ＤＢ、ダークネット観測ＤＢあるいは悪性ＷｅｂサイトＤＢを含む。
【発明の効果】
【００２４】
本発明によって、ユーザのウェブブラウジングのアクセス先の多様性の影響を除外することでホワイトリスト作成の困難さを軽減し、リスト漏れによる誤検知（ユーザビリティの低下）を抑えつつ高い検知率を実現できる。
【図面の簡単な説明】
【００２５】
【図１】本発明の構成例を示すブロック図である。
【図２】データベース９の構成例を示すブロック図である。
【図３】ゲートウェイセンサ３で観測された各フローを検査する際の本発明のフローチャート例を示す。
【図４】Ｗｅｂプロキシサーバ１０が存在する場合の構成例を示すブロック図である。
【図５】Ｗｅｂプロキシサーバ１０が有る場合の本発明のフローチャート例を示す。
【図６】観測されたアクセス先ホストコンピュータ名の一覧を示す。
【図７】平日のある日の２４時間に観測されたＮＩＣＴ（登録商標）内部ホストコンピュータからインターネット上のホストコンピュータに対するＴＣＰ／ＳＹＮパケットとＵＤＰパケットの統計を示す。
【図８】観測されたパケットについて、宛先ＩＰアドレスと宛先ポートの組み合わせで見たときのユニーク数をカウントした統計を示す。
【発明を実施するための形態】
【００２６】
以下に、この発明の実施の形態を図面に基づいて詳細に説明する。以下の説明においては、同じ機能あるいは類似の機能をもった装置に、特別な理由がない場合には、同じ符号を用いるものとする。
また、以下におけるウェブブラウザとは、次の部分から構成され、ユーザが情報リソースを提示するもので、例えば、Internet Explorer（登録商標）、Firefox（登録商標）、Chrome（登録商標）などである。
１．  URI, HTTP 等に基き、サーバと通信してリソースを取得する、HTTP ユーザエージェントの部分。
２．  取り寄せた資源をその種類 (HTML/XHTML/XML, 文書、画像等）に応じて解析する構文解析の部分。
３．  構文解析の結果を基に文字や画像を適切に配置したり、文字の大きさを調整したり、あるいは色を付けたり、などして最終的に人間の為の表示を行う描写の部分。
また、以下におけるマルウェアとは、ユーザの望まない不正な動作を行うソフトウェアの総称（例えば、コンピュータウイルス、ワーム、スパイウェア、トロイの木馬、ボットなどである。
また、以下におけるゲートウェイとは、内部ネットワークと外部ネットワークの境界に設置され、それらを相互接続するためのネットワークノードをいう（例えば、ルータなど）。
【００２７】
具体的には、監視対象のホストコンピュータがインターネットを介して行う全通信を観測するゲートウェイセンサの観測情報と、上記ホストコンピュータ上で動作しているＷｅｂサイト閲覧ソフトによる通信を観測するホストセンサの観測情報とを突合することで、上記Ｗｅｂサイト閲覧ソフト以外による通信を抽出する。しかし、抽出された通信の中にはオペレーティングシステム（ＯＳ）による通信やブラウザ以外の正規のアプリケーションによる通信も含まれる。このため、それらの通信のアクセス先については予めホワイトリスト化し、上記の抽出された通信からホワイトリスト上のものを除外することで、マルウェアの行う不正通信を検出可能とする。
【実施例１】
【００２８】
Ｗｅｂプロキシを用いない場合の実施例について以下に説明する。
本発明では、複数のセンサで観測された情報を基にマルウェアが行う通信を検知する。まず、組織内ネットワークとインターネット間のゲートウェイなど監視対象の各ホストコンピュータの全通信を観測可能な場所にネットワークセンサを設置し、各ホストコンピュータが行う全通信のアクセス先情報を収集する。また、各ホストコンピュータ上で動作させたホストセンサによって Ｗｅｂサイト閲覧ソフトが行う通信のアクセス先情報のみを収集する。各センサで収集された情報を集約し突合することで、各ホストコンピュータからのＷｅｂサイト閲覧ソフトの通信を除いた全通信のアクセス先情報が抽出される。この中には、ＯＳや正規のアプリケーションによる通信のアクセス先情報も含まれるが、それらはホワイトリスト化し除外することで、マルウェアの行う不正通信のみを検知可能となる。
【００２９】
本発明によって、ホワイトリスト的アプローチにおけるホワイトリスト作成の課題点であったユーザのウェブブラウジングのアクセス先の多様性の影響を除外することが可能になり、ホワイトリスト漏れによるユーザビリティの低下を抑えたまま、不正通信の検知が可能になる。
【００３０】
また、ネットワーク上とホストコンピュータ上という複数地点でのセンサによる観測情報を用いることで、ホストコンピュータ上またはネットワーク上のみで観測するよりも、マルウェアによる検知回避を困難にすることができる。
【００３１】
特に、高いセキュリティが求められる企業や官公庁などの組織内ネットワークに導入することで、マルウェア感染の早期検知が可能になり、情報漏洩等の被害軽減が期待できる。
【００３２】
図１に本発明の構成例のブロック図を示す。
ここで、外部ネットワーク１は、内部ネットワーク以外のネットワーク、例えば、WAN（Wide Area Network）やインターネットを指す。
【００３３】
また、ゲートウェイ２は、内部ネットワークの全てのホストコンピュータ５が外部ネットワークへ通信を行う際に必ず通過する装置である。例えば、内部ネットワークと外部ネットワークの境界に設置されたファイヤフォールやルータなどが該当する。
【００３４】
ゲートウェイセンサ３は、ゲートウェイに設置され、内部ネットワーク内のホストコンピュータ５から外部ネットワークへの通信に関して、内部ネットワーク内のホストコンピュータのIPアドレスとアクセス先のIPアドレス、ポート番号を収集し、当該アクセス先情報を突合処理部へと送信する。
【００３５】
DNSサーバ４は、内部ネットワーク内のホストコンピュータ５が外部ネットワークへのアクセスの際にDNS名前解決するために用いるサーバ。DNSサーバはホストコンピュータ５がDNS名前解決した際の情報を突合処理部へと送信する。具体的には、ホストコンピュータ５のIPアドレス、DNS名前解決したホスト名、ホスト名から得られたIPアドレス、の情報を送信する。ホスト名とIPアドレスを突合する際には、DNSサーバ４のログを用いて適宜ホスト名とIPアドレスの対応関係を取る。
【００３６】
ホストセンサ７は、ホストコンピュータ５上で動作し、各ホストコンピュータ５上で動作するWebサイト閲覧ソフト６による通信のアクセス先情報を収集し、突合処理部８へと送信する。具体的には、自身のIPアドレス、アクセス先のIPアドレスまたはホスト名とポート番号を収集し、突合処理部８へと送信する。
【００３７】
突合処理部８は、各エンティティからの情報を収集する。また、ゲートウェイセンサ３から得られた各ホストコンピュータ５のアクセス先情報とデータベース９内のスパムメールDB９ｂ、レピュテーションDB９ｃ、マルウェア動的解析DB９ｄ、ダークネット観測DB９ｅ、悪性WebサイトDB９ｆを突合し、いずれかのDBにアクセス先情報が存在した場合、当該アクセス先への通信を不正通信として検出する。また、上記に該当しないゲートウェイセンサ３から得られた各ホストコンピュータ５のアクセス先情報のうち、各ホストセンサ５から得られたアクセス先情報を除外したリストを生成する。当該リストに含まれるアクセス先情報とデータベース９内のホワイトリストDB９ａを突合し、ホワイトリストDB９ａ内に含まれないアクセス先情報が存在した場合、当該アクセス先への通信を不正通信として検出する。
【００３８】
データベース９は、突合処理部８での突合処理に利用される。図２に示す様に、データベース９は、正規のアクセス先情報を保持するホワイトリストDB９ａ、悪性のアクセス先情報を保持するスパムメールDB９ｂ、レピュテーションDB９ｃ、マルウェア動的解析DB９ｄ、ダークネット観測DB９ｅ、および悪性WebサイトDB９ｆを含む。
ホワイトリストDB９ａは、正規のアクセス先情報（IPアドレスorホスト名、ポート番号）を保持する。
スパムメールDB９ｂは、スパムメールの送信元情報やスパムメールの文面に記載された悪性Webサイトの情報（IPアドレスorホスト名、ポート番号）を含む。
レピュテーションDB９ｃ、ドメイン名の登録情報などから各アクセス先の評価値を算出し、危険性が高いと判定されたアクセス先情報（IPアドレスorホスト名、ポート番号）を保持する。
マルウェア動的解析DB９ｄは、マルウェア動的解析の結果得られた、C&C（Command & Control）サーバやマルウェア配布サーバの情報（IPアドレスorホスト名、ポート番号）を含む。
ダークネット観測DB９ｅは、ダークネット（未使用のIPアドレス空間）観測によって観測された、攻撃元コンピュータの情報（IPアドレスorホスト名、ポート番号）を含む。
悪性WebサイトDB９ｆは、クライアントハニーポットなどで観測されたドライブ・バイ・ダウンロード（Drive-by-Download）攻撃サイトの情報（IPアドレスorホスト名、ポート番号）を含む。
【００３９】
ゲートウェイセンサ３で観測された各フローを検査する際の本発明のフローチャート例を図３に示す。なお、図３および図５では他センサの観測情報との突合部分については省略している。図３の処理の流れを基に、ゲートウェイセンサ３から観測される各フローに対して、リアルタイムもしくは一定時間毎にアラート判定を行う。
【００４０】
図３のフローチャートにおいて、各ステップは以下の如し。
Ｆ０：  開始。
Ｆ１：  まず、ゲートウェイセンサ３のログから監視対象のホストコンピュータ５の開始したフローの送信元ＩＰアドレス（SrcIP）、宛先ＩＰアドレス（DstIP）、宛先ポート（DstPort）を取得する。
Ｆ２：  次に、悪性アクセス先情報に、つまり悪性WebサイトDB９ｆ内に、（DstIP/ DstDomain（宛先ドメイン）、DstPort）の組み合わせで一致するものが存在するか確認する。存在する場合はＦ６へ、存在しない場合はＦ３へ進む。ここで、「/」は、「または」を表す。
Ｆ３：  ホストセンサ７のログ（つまりデータ）内に（SrcIP、DstIP、DstPort）の組み合わせで一致するものが存在するか確認する。存在しない場合はＦ４へ、存在する場合はＦ７へ進む。
Ｆ４：  ホワイトリストDB９ａに（DstDomain、DstPort）の組み合わせで一致するものが存在するか確認する。存在する場合はＦ６へ、存在しない場合はＦ５へ進む。
Ｆ５：  アラートを出力する。
Ｆ６：  終了。
【実施例２】
【００４１】
Ｗｅｂプロキシを用いる場合の実施例について以下に説明する。
企業や大学等の組織のネットワークでは、内部ホストコンピュータからのＷｅｂアクセスの際にＷｅｂプロキシを経由する構成になっている場合がある。その場合、各ホストコンピュータ上のホストセンサからはインターネット上のサーバのＩＰアドレスが観測できないため、突合の際に別途Ｗｅｂプロキシサーバのログを用いる必要がある。
【００４２】
このようにＷｅｂプロキシサーバ（つまり代理手段）が存在する場合の全体の概要図を図４に示す。
ここで、Webプロキシサーバ１０は、内部ネットワークのホストコンピュータ５から外部ネットワーク１へのWebアクセスの際に、ホストコンピュータ５の代理でWebアクセスを行うサーバである。Webプロキシサーバ１０にアクセスしたホストコンピュータ５のIPアドレス、Webプロキシサーバ１０が代理でアクセスしたWebサーバのホスト名、IPアドレス、ポート番号を収集し、突合処理部８へ送信する。
図４の構成は、図１の構成にＷｅｂプロキシサーバ１０が追加された以外は、図１の構成と基本的には同じであるが、例えば以下の点で異なっている。
（１）  Ｗｅｂプロキシサーバ１０経由の通信では、ゲートウェイセンサ３で観測される送信元ＩＰアドレス（DstIP）は監視対象の各ホストコンピュータ５ではなくＷｅｂプロキシのＩＰアドレスになる。
（２）  Ｗｅｂサイト閲覧ソフト通信に関して、ホストセンサ７からはインターネット上のサーバのＩＰアドレスは観測できない。そのためホストセンサ７はＨＴＴＰリクエストなどから宛先ホストコンピュータ名と宛先ポート、つまり（DstDomain、DstPort）、を収集する必要がある。
（３）  ホストセンサ７とゲートウェイセンサ３の観測情報の突合を行うためにＷｅｂプロキシサーバ１０のログを収集する。Ｗｅｂプロキシサーバ１０では、内部ホストコンピュータのＩＰアドレス、宛先ホストコンピュータ名、宛先ＩＰアドレス、宛先ポート、つまり（SrcIP、DstDomain、DstIP、DstPort）、を収集する。
【００４３】
図５にＷｅｂプロキシサーバ１０が有る場合の本発明のフローチャート例を示す。
Ｇ０：  開始。
Ｇ１：  まず、ゲートウェイセンサ３のログから監視対象のホストコンピュータ５の開始したフローの送信元ＩＰアドレス、宛先ＩＰアドレス、宛先ポート、つまり（SrcIP、DstIP、DstPort）、を取得する。
Ｇ２：  次に、悪性アクセス先情報に、つまり悪性WebサイトDB９ｆ内に、（DstIP/DstDomain、DstPort）の組み合わせで一致するものが存在するか確認する。存在する場合はＧ７へ、存在しない場合はＧ３へ進む。ここで、「/」は「または」を表す。
Ｇ３：  Ｗｅｂプロキシサーバ１０のログ（つまりデータ）内に（SrcIP、DstIP、DstPort）の組み合わせで一致するものが存在するか確認する。存在しない場合はＧ６へ、存在する場合はＧ４へ進む。
Ｇ４：  Ｗｅｂプロキシサーバ１０のログから（SrcIP,DstDomaint）の組み合わせを取得する。
Ｇ５：  ホストセンサ７のログに（SrcIP、DstIP、DstPort）の組み合わせで一致するものが存在するか確認する。存在する場合はＧ８へ、存在しない場合はＧ６へ進む。
Ｇ６：  ホワイトリストDB９ａに（DstIP/DstDomain、DstPort）の組み合わせで一致するものが存在するか確認する。存在する場合はＧ８へ、存在しない場合はＧ７へ進む。
Ｇ７：  アラートを出力する。
Ｇ８：  終了。
【００４４】
この場合も、図５の処理の流れを基に、ゲートウェイセンサから観測される各フローに対して、リアルタイムもしくは一定時間毎にアラート判定を行う。上記と同様に、すでによく知られたアラートの利用方法を適用して、ユーザの便宜を図ることは容易である。
【実施例３】
【００４５】
次に、上記の本発明に関する実験について説明する。
まず、ホワイトリスト作成に関して、ユーザの操作が無い状態で自動的に発生する通信のアクセス先情報を把握するために、事務作業用ＰＣ１台（Windows（登録商標）7 Professional SP1）を３日間２０時から翌日８時頃まで起動状態で放置した際の通信を観測した。図６の表１に、観測されたアクセス先ホストコンピュータ名の一覧を示す（ただし、ＮＩＣＴ（登録商標）（独立行政法人情報通信研究機構）内部のサーバのホストコンピュータ名は除外している）。なお、ＤＮＳ名前解決無しで直接外部のＩＰアドレスへアクセスした通信は、観測されなかった。
【００４６】
図６の表1を見ると、基本的には“Microsoft”（登録商標）に関連したアクセス先が大半であり、一部導入しているウイルス対策ソフトのアクセスや（Symantec（登録商標）関連）、Adobe（登録商標）関連のアクセスがあるものの、３日間で観測されたホストコンピュータ名は１７個と少ないことがわかる。
【００４７】
図６の表１のホストコンピュータ名は何も操作していない状態で観測されたものであるため、実際にユーザが使用している環境では図６の表１以外のアクセス先に対して他の正規アプリケーション等による通信が発生するはずである。しかし、大半のアプリケーションによるアクセス先はいくつかの固定のアクセス先に限定されると予想されるため、ホワイトリストでの対応は十分に可能であると考えられる。なお、不特定多数のアクセス先と通信を行うソフトウェアに関しては、後段に記載する。
【００４８】
本発明は企業等の組織のネットワークへの適用を想定している。そこで、ゲートウェイセンサで観測・検査対象となるトラフィック量の関する参考情報として、ＮＩＣＴ（登録商標）のネットワークにおけるトラフィック観測を行った。図７に、平日のある日の２４時間に観測されたＮＩＣＴ（登録商標）内部ホストコンピュータからインターネット上のホストコンピュータに対するＴＣＰ／ＳＹＮパケットとＵＤＰパケットの統計を示している。ただし、ＵＤＰパケットについてはＤＮＳ（Port 53）とＮＴＰ（Port 123）に関連するものは除外した。なお、ＮＩＣＴ内部ホストコンピュータ数については、この２４時間の観測期間中に、約２，６００個のＩＰアドレスからのトラフィックが観測されている。図７を見ると、多少変動はあるものの、昼間はＴＣＰ／ＳＹＮパケットが毎分２０，０００パケット程度、ＵＤＰパケットが毎分７，０００パケット程度観測されている。一方夜間はＴＣＰ／ＳＹＮパケットとＵＤＰパケットの両方とも毎分３，０００パケット程度となっている。
【００４９】
これらのデータからＮＩＣＴ（登録商標）ネットワークに本発明を適用した場合、昼間で約３０，０００弱／分、夜間で約６，０００／分のフローの検査が必要になることが分かる。ちなみに、１３時から１５時の間に、大量のＵＤＰパケットが観測されているが、この原因は、あるＮＩＣＴ内部ホストコンピュータと外部の一つのホストコンピュータが大量のＵＤＰパケットの送受信を行なったことによるものである。
【００５０】
図８に、観測されたパケットについて、宛先ＩＰアドレスと宛先ポートの組み合わせで見たときのユニーク数をカウントした統計を示す。ＴＣＰ／ＳＹＮパケットについては昼間で約１，４００／分、夜間で約５００／分、ＵＤＰパケットについては昼間で約１００／分、夜間で約５０／分であった。実際の運用時には、一定時間内に観測された同一宛先ＩＰアドレス、宛先ポートへのフローの検査を省略するなどして効率化を試みる場合が考えられる。しかし、今回の観測データを見る限りでは、１分間で観測されたフローの内、ユニークな宛先ＩＰアドレス、宛先ポートのフローのみを検査することで、検査対象となるフロー数の大幅な削減が期待できることが分かる。
【００５１】
次に、不特定多数と通信を行うソフトウェアの場合について説明する。
本発明では、Ｗｅｂサイト閲覧ソフト以外のＯＳや正規ソフトウェアのアクセス先をホワイトリスト化する。そのため、Skype（登録商標）やBitTorrent（登録商標）などのＰ２Ｐ（Peer to Peer）ソフトウェアのような不特定多数のホストコンピュータと接続を行うソフトウェアに関しては、アクセス先のリスト化が容易ではないため対応が困難である。そのため、組織内でそれらＰ２Ｐソフトウェアの利用を許可するためには、Ｗｅｂサイト閲覧ソフトと同様にホストセンサによる監視が必要になる。しかし、監視対象が増えることによるホストセンサの実装方法への影響やオーバーヘッドの増加等については検討する必要がある。
【００５２】
本発明では、初期ホワイトリストを如何に作成するかが一つの課題となる。一つの方法としては、ホストセンサとゲートウェイセンサを導入した後、一定期間は観測のみを行う期間とし、その間に観測されたＷｅｂサイト閲覧ソフト以外のアクセス先を初期ホワイトリストとして用いる方法が考えられる。またインターネットアクセスを必要とする新たなソフトウェアをインストールする際や、ユーザがＳＳＨやＦＴＰで新規のアクセス先にアクセスする場合などは、ホワイトリストへの追加が必要になるため、リストの管理・更新などの運用時にかかる作業とコストについても検討が必要である。
【００５３】
本発明では、上記の様に、ゲートウェイセンサで全ての通信を観測し、ホストセンサで観測された通信をＷｅｂサイト閲覧ソフトからの通信と判断して検査対象から除外する。このため、例えばルートキットのようなホストコンピュータ上での観測を回避しようとするアプローチは、本発明に対して効果が無い。
【００５４】
しかし、例えばＷｅｂサイト閲覧ソフトのプロセスにインジェクションして通信を行うマルウェアの場合、ホストセンサの実装具合によっては、それらの通信がウェブブラウザの通信として観測されることで、検査対象から除外され、検知を回避されてしまう。他にも、ホストセンサになりすましてマルウェアが突合用サーバに偽情報を送ることで回避する方法や、ＤＮＳ通信をＣ＆Ｃ通信に用いることで突合を難しくする方法なども考えられるが、これらの課題に対処することは容易である。
【産業上の利用可能性】
【００５５】
また、本発明は、企業などの組織のネットワークへの適用を想定している。ゲートウェイセンサは監視対象の全ホストコンピュータとインターネット間の通信を全て観測可能な地点に設置し、監視対象ホストコンピュータから開始された通信についてフロー単位で送信元ＩＰアドレスと宛先ＩＰアドレス、宛先ポートの情報、つまり（SrcIP、DstIP、DstPort）、を収集する。ゲートウェイセンサの具体的な実現方法としてはポートミラーリングやネットフロー（NetFlow）を利用する方法やファイヤウォールのログを利用する方法などが考えられる。
【符号の説明】
【００５６】
１  外部ネットワーク
２  ゲートウェイ
３  ゲートウェイセンサ
４  DNSサーバ
５  ホストコンピュータ
６  Webサイト閲覧ソフト
７  ホストセンサ
８  突合処理部
９  データベース
９ａ  ホワイトリストDB
９ｂ  スパムメールDB
９ｃ  レピュテーションDB
９ｄ  マルウェア動的解析DB
９ｅ  ダークネット観測DB
９ｆ  悪性WebサイトDB
【図１】
2014099758.tif 000003
【図２】
2014099758.tif 000004
【図３】
2014099758.tif 000005
【図４】
2014099758.tif 000006
【図５】
2014099758.tif 000007
【図６】
2014099758.tif 000008
【図７】
2014099758.tif 000009
【図８】
2014099758.tif 000010