(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-03-24
(45)【発行日】2022-04-01
(54)【発明の名称】情報処理装置、通信検査方法及びプログラム
(51)【国際特許分類】
H04L 12/66 20060101AFI20220325BHJP
G06F 21/55 20130101ALI20220325BHJP
H04L 12/22 20060101ALI20220325BHJP
【ＦＩ】
H04L12/66
G06F21/55
H04L12/22
【請求項の数】
18
(21)【出願番号】P 2018133547
(22)【出願日】2018-07-13
(65)【公開番号】P2020014061
(43)【公開日】2020-01-23
【審査請求日】2020-10-12
(73)【特許権者】
【識別番号】000136136
【氏名又は名称】株式会社ＰＦＵ
(74)【代理人】
【識別番号】100145838
【弁理士】
【氏名又は名称】畑添 隆人
(74)【代理人】
【識別番号】100103137
【弁理士】
【氏名又は名称】稲葉 滋
(72)【発明者】
【氏名】寺田 成吾
(72)【発明者】
【氏名】道根 慶治
(72)【発明者】
【氏名】小林 峻
【審査官】中川 幸洋
(56)【参考文献】
【文献】国際公開第２０１７／０６１４６９（ＷＯ，Ａ１）
【文献】特開２０１７－０５９９６４（ＪＰ，Ａ）
【文献】小川 秀貴、ほか，リクエスト間隔とレスポンスのボディサイズに基づくマルウェア感染由来のHTTPトラフィック検知，コンピュータセキュリティシンポジウム2016論文集，情報処理学会，2016年10月04日，pp. 408 - 415
【文献】石井 将大、ほか，エントロピーを特徴として用いた初期潜入段階におけるRATの通信検知，電子情報通信学会論文誌 B，Vol.J101-B No.3，2018年03月01日，pp.220-232
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ １２／６６
Ｇ０６Ｆ ２１／５５
Ｈ０４Ｌ １２／２２
(57)【特許請求の範囲】
【請求項1】
ネットワークに接続された端末による通信データを取得する通信データ取得手段と、取得された前記通信データに係る通信に含まれる特徴を抽出する特徴抽出手段と、
抽出された特徴を用いて、同一の通信先に係る複数の通信を比較し、該複数の通信間の類似度を算出する類似度算出手段と、
同一の通信先に係る、類似度が所定以上の通信が所定数以上検出された場合に、取得された前記通信データに基づいて、同一の通信先に係る複数の通信の属性情報の分布を算出する分布算出手段と、
算出された前記分布が所定の基準を満たすか否かを判定することで、検出された通信が所定の種類のソフトウェアによる通信であるか否かを推定する推定手段と、
を備える情報処理装置。
【請求項2】
前記分布算出手段は、前記属性情報の分布として、通信に係るタイミングの規則性、及び通信に係るデータサイズの偏り、の少なくとも何れかを算出し、前記推定手段は、前記分布算出手段による処理の結果を参照して、所定以上の規則性を有するか、又は偏りが所定以上であるかを判定することで、検出された通信が所定の種類のソフトウェアによる通信であるか否かを推定する、
請求項１に記載の情報処理装置。
【請求項3】
前記分布算出手段は、前記複数の通信のうち、通信に係るタイミング又はデータサイズが所定の範囲の外にある通信を除いた通信について、前記属性情報の分布を算出する、請求項２に記載の情報処理装置。
【請求項4】
前記分布算出手段は、単一の宛先へのデータのリクエスト送信タイミングについて、前記分布を算出する、請求項３に記載の情報処理装置。
【請求項5】
前記分布算出手段は、前記複数の通信がＨＴＴＰ通信である場合に、単一の宛先へのＧＥＴメソッド又はＰＯＳＴ／ＰＵＴメソッドに係るリクエスト送信タイミングについて、前記分布を算出する、請求項４に記載の情報処理装置。
【請求項6】
前記分布算出手段は、前記複数の通信がＳＳＬ／ＴＬＳ通信である場合に、単一の宛先へのＣｌｉｅｎｔＨｅｌｌｏメッセージと該ＣｌｉｅｎｔＨｅｌｌｏメッセージの直後のＣｌｉｅｎｔＨｅｌｌｏメッセージとの間隔について、前記分布を算出する、請求項４に記載の情報処理装置。
【請求項7】
前記分布算出手段は、単一の宛先へのレスポンスに係るデータ長について、前記分布を算出する、請求項３に記載の情報処理装置。
【請求項8】
前記分布算出手段は、実行ファイルのダウンロードを除くレスポンスにおけるヘッダー部を除くデータ長について、単一の宛先へのＧＥＴメソッド又はＰＯＳＴ／ＰＵＴメソッド毎に、前記分布を算出する、請求項７に記載の情報処理装置。
【請求項9】
前記分布算出手段は、所定サイズ以上のレスポンスを除く、単一の宛先へのレスポンスに係るデータ長について、前記分布を算出する、請求項７に記載の情報処理装置。
【請求項10】
前記特徴抽出手段は、取得された前記通信データに係る通信に含まれる要素毎に特徴を抽出し、前記類似度算出手段は、前記要素毎に前記複数の通信間の要素類似度を算出し、算出された要素類似度を該要素毎に重み付けすることで、前記複数の通信間の総合類似度を算出する、
請求項１から９のいずれか一項に記載の情報処理装置。
【請求項11】
前記類似度算出手段は、前記要素に係る特徴の共通度又は前記要素に係る特徴の組み合わせ間の距離に基づいて、要素類似度を算出する、請求項１０に記載の情報処理装置。
【請求項12】
前記特徴抽出手段は、前記複数の通信に含まれるリクエストヘッダーの並び順についての特徴を抽出し、前記類似度算出手段は、前記リクエストヘッダーの並び順についての要素類似度を算出する、
請求項１０又は１１に記載の情報処理装置。
【請求項13】
前記類似度算出手段は、前記推定手段によって前記所定の種類のソフトウェアによる通信であると推定された第一の通信と、前記ネットワークに接続された端末のうち該第一の通信を行った端末とは異なる第二の端末による第二の通信と、の類似度を更に算出し、前記推定手段は、前記類似度算出手段によって算出された、前記第一の通信と前記第二の通信との類似度が所定以上である場合に、前記第二の端末を、前記第一の通信に係るソフトウェアと同じグループに属するソフトウェアが動作する端末であると推定する、
請求項１から１２の何れか一項に記載の情報処理装置。
【請求項14】
前記推定手段は、当該情報処理装置によって管理される端末の数に対して、前記第一の通信に対する類似度が所定以上である通信を行なう端末の数が占める割合が所定割合以上である場合、前記第一の通信が、前記所定の種類のソフトウェアによる通信であるとの推定を取り消す、請求項１３に記載の情報処理装置。
【請求項15】
前記類似度算出手段は、前記推定手段によって前記所定の種類のソフトウェアによる通信であると推定された第一の通信と、既知のソフトウェアによる既知の通信と、の類似度を更に算出し、前記推定手段は、前記類似度算出手段によって算出された、前記第一の通信と前記既知の通信との類似度が所定以上である場合に、前記第一の通信を、前記既知のソフトウェアと同じグループに属するソフトウェアによる通信であると推定する、
請求項１から１４の何れか一項に記載の情報処理装置。
【請求項16】
前記推定手段は、算出された前記分布が、マルウェア通信における所定のフェーズについて用意された判定基準を満たすか否かを判定することで、検出された通信がマルウェアによる該所定のフェーズの通信であるか否かを推定する、請求項１から１５の何れか一項に記載の情報処理装置。
【請求項17】
コンピューターが、ネットワークに接続された端末による通信データを取得する通信データ取得ステップと、
取得された前記通信データに係る通信に含まれる特徴を抽出する特徴抽出ステップと、
抽出された特徴を用いて、同一の通信先に係る複数の通信を比較し、該複数の通信間の類似度を算出する類似度算出ステップと、
同一の通信先に係る、類似度が所定以上の通信が所定数以上検出された場合に、取得された前記通信データに基づいて、同一の通信先に係る複数の通信の属性情報の分布を算出する分布算出ステップと、
算出された前記分布が所定の基準を満たすか否かを判定することで、検出された通信が所定の種類のソフトウェアによる通信であるか否かを推定する推定ステップと、
を実行する通信検査方法。
【請求項18】
コンピューターを、ネットワークに接続された端末による通信データを取得する通信データ取得手段と、
取得された前記通信データに係る通信に含まれる特徴を抽出する特徴抽出手段と、
抽出された特徴を用いて、同一の通信先に係る複数の通信を比較し、該複数の通信間の類似度を算出する類似度算出手段と、
同一の通信先に係る、類似度が所定以上の通信が所定数以上検出された場合に、取得された前記通信データに基づいて、同一の通信先に係る複数の通信の属性情報の分布を算出する分布算出手段と、
算出された前記分布が所定の基準を満たすか否かを判定することで、検出された通信が所定の種類のソフトウェアによる通信であるか否かを推定する推定手段と、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ネットワーク上の通信を検査する技術に関する。
【背景技術】
【0002】
従来、複数の観測点で収集されたアクセスデータを、検知対象アクセス元毎に分類し、検知対象アクセス元毎のネットワーク的特徴量を生成して、アクセス元検知部が、ネットワーク的特徴量を基に、所定の連続アクセスを行なっているアクセス元を検知し、点的特徴量生成部が、単一の観測点で収集されたアクセスデータ毎の特徴量である検知対象点的特徴量と、アクセス元検知部によって検知されたアクセス元のアクセスデータ毎の特徴量である教師点的特徴量と、を生成して、アクセス検知部が、検知対象点的特徴量の教師点的特徴量との類似度が所定値以上であるアクセスデータを、所定の連続アクセスによるアクセスデータとして検知する技術が提案されている（特許文献１を参照）。
【0003】
また、電子証明書を検査することで不正な証明書を利用したマルウェアの通信を検出する技術（特許文献２を参照）や、Ｃ＆Ｃ通信の特徴としてｂａｇ－ｏｆ－ｗｏｒｄｓ（単語の頻出度）によるＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ヘッダーの種類の頻出度を利用すること（非特許文献１を参照）が提案されている。
【先行技術文献】
【特許文献】
【0004】
【文献】国際公開２０１７／１４５８４３号
【文献】特開２０１７－９８８７６号公報
【非特許文献】
【0005】
【文献】Ｈｉｄｅｋｉ Ｏｇａｗａ他、「Ｍａｌｗａｒｅ ｏｒｉｇｉｎａｔｅｄ ＨＴＴＰ ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ ｕｔｉｌｉｚｉｎｇ ｃｌｕｓｔｅｒ ａｐｐｅａｒａｎｃｅ ｒａｔｉｏ」、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｎｅｔｗｏｒｋｉｎｇ（ＩＣＯＩＮ）、２０１７年１月１１日
【発明の概要】
【発明が解決しようとする課題】
【0006】
従来、所定の種類のソフトウェア（例えば、マルウェア）による通信を検出するために、シグネチャ照合によってシステムへの脅威を検知する技術や、ネットワーク上の端末等の振る舞いの怪しさを判定することで、システムへの脅威を検知する技術が用いられている。しかし、近年では、例えば、ブラウザの通信を偽装したＨＴＴＰベースのＣ＆Ｃ通信や、正当なＳＳＬサーバ証明書を使用したＳＳＬ／ＴＬＳ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ／Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）ベースのＣ＆Ｃ通信を行なうマルウェア等が急速に増加し、マルウェアが行なう通信が巧妙に正常な通信（例えば、通常の業務通信）を偽装するようになっている。このため、上記した従来の検出技術では、業務通信とマルウェア通信とを見分けることは困難である。
【0007】
本開示は、上記した問題に鑑み、所定の種類のソフトウェアによる、正常な通信に偽装した通信を検出することを課題とする。
【課題を解決するための手段】
【0008】
本開示の一例は、ネットワークに接続された端末による通信データを取得する通信データ取得手段と、取得された前記通信データに基づいて、同一の通信先に係る複数の通信の属性情報の分布を算出する分布算出手段と、算出された前記分布が所定の基準を満たすか否かを判定することで、検出された通信が所定の種類のソフトウェアによる通信であるか否かを推定する推定手段と、を備える情報処理装置である。
【0009】
本開示は、情報処理装置、システム、コンピューターによって実行される方法またはコンピューターに実行させるプログラムとして把握することが可能である。また、本開示は、そのようなプログラムをコンピューターその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピューター等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的または化学的作用によって蓄積し、コンピューター等から読み取ることができる記録媒体をいう。
【発明の効果】
【0010】
本開示によれば、所定の種類のソフトウェアによる、正常な通信に偽装した通信を検出することが可能となる。
【図面の簡単な説明】
【0011】
【図1】実施形態に係るシステムの構成を示す概略図である。
【図2】実施形態に係るネットワーク監視装置および管理サーバーのハードウェア構成を示す図である。
【図3】実施形態に係る管理サーバーの機能構成の概略を示す図である。
【図4】実施形態に係る通信検査処理の流れの概要を示すフローチャートである。
【図5】実施形態に係るＣ＆Ｃ通信検出処理（ＨＴＴＰ）の流れの概要を示すフローチャートである。
【図6】実施形態に係るＣ＆Ｃ通信検出処理（ＳＳＬ／ＴＬＳ）の流れの概要を示すフローチャートである。
【図7】実施形態に係る感染範囲推定処理（ＨＴＴＰ）の流れの概要を示すフローチャートである。
【図8】実施形態に係るマルウェア・ファミリー推定処理（ＨＴＴＰ）の流れの概要を示すフローチャートである。
【図9】実施形態に係るシステムの構成のバリエーションを示す概略図である。
【発明を実施するための形態】
【0012】
以下、本開示に係る情報処理装置、通信検査方法及びプログラムの実施の形態を、図面に基づいて説明する。但し、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、通信検査方法及びプログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の態様に応じた具体的構成が適宜採用され、また、種々の改良や変形が行われてよい。
【0013】
本実施形態では、本開示に係る情報処理装置、通信検査方法及びプログラムを、ネットワーク上での不正な活動を発見し、通信遮断やアラート通知等の対処を行うためのシステムにおいて実施した場合の実施の形態について説明する。但し、本開示に係る情報処理装置、通信検査方法及びプログラムは、ネットワーク上の通信を検査するために広く用いることが可能であり、本開示の適用対象は、本実施形態において示した例に限定されない。
【0014】
＜システムの構成＞
図１は、本実施形態に係るシステム１の構成を示す概略図である。本実施形態に係るシステム１は、複数の情報処理端末９０（以下、「ノード９０」と称する）が接続されるネットワークセグメント２と、ノード９０に係る通信を監視するためのネットワーク監視装置２０（通信監視装置）と、ルータ１０を介してネットワークセグメント２と通信可能に接続された管理サーバー５０と、を備える。
図１は、本実施形態に係るシステム１の構成を示す概略図である。本実施形態に係るシステム１は、複数の情報処理端末９０（以下、「ノード９０」と称する）が接続されるネットワークセグメント２と、ノード９０に係る通信を監視するためのネットワーク監視装置２０（通信監視装置）と、ルータ１０を介してネットワークセグメント２と通信可能に接続された管理サーバー５０と、を備える。
【0015】
本実施形態において、ネットワーク監視装置２０は、スイッチまたはルータ（図１に示した例では、ルータ）のモニタリングポート（ミラーポート）に接続されることで、ノード９０によって送受信されるパケットやフレーム等の通信データを取得し、取得した通信データを管理サーバー５０に送信する。この場合、ネットワーク監視装置２０は、取得したパケットを転送しないパッシブモードで動作してもよい。
【0016】
管理サーバー５０は、ネットワーク監視装置２０から情報を収集し、ネットワーク監視装置２０を管理する。なお、外部ネットワークには、更に検疫サーバーが設けられ、ネットワークセグメント２に接続されたノード９０に対して検疫サービスを提供してもよいし、業務サーバーが設けられ、ノード９０に対して業務のためのサービスを提供してもよい（図示は省略する）。
【0017】
本実施形態に係るシステム１では、ノード９０から接続される各種サーバーは、インターネットや広域ネットワークを介して遠隔地において接続されたものであり、例えばＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）によって提供されるが、これらのサーバーは、必ずしも遠隔地に接続されたものである必要はない。例えば、これらのサーバーは、ノード９０やネットワーク監視装置２０が存在するローカルネットワーク上に接続されていてもよい。
【0018】
図２は、本実施形態に係るネットワーク監視装置２０および管理サーバー５０のハードウェア構成を示す図である。なお、図２においては、ネットワーク監視装置２０および管理サーバー５０以外の構成（ルータ１０、ノード９０等）については、図示を省略している。ネットワーク監視装置２０および管理サーバー５０は、それぞれ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１ａ、１１ｂ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３ａ、１３ｂ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２ａ、１２ｂ、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶装置１４ａ、１４ｂ、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）１５ａ、１５ｂ等の通信ユニット、等を備えるコンピューターである。
【0019】
図３は、本実施形態に係る管理サーバー５０の機能構成の概略を示す図である。管理サーバー５０は、記憶装置１４ｂに記録されているプログラムが、ＲＡＭ１３ｂに読み出され、ＣＰＵ１１ｂによって実行されて、管理サーバー５０に備えられた各ハードウェアが制御されることで、通信データ取得部２１、特徴抽出部２２、類似度算出部２３、分布算出部２４及び推定部２５を備える情報処理装置として機能する。なお、本実施形態及び後述する他の実施形態では、管理サーバー５０の備える各機能は、汎用プロセッサであるＣＰＵ１１ｂによって実行されるが、これらの機能の一部または全部は、１または複数の専用プロセッサによって実行されてもよい。
【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】
ステップＳ１１５では、対象通信がＣ＆Ｃ通信であると推定される。ステップＳ１１１からステップＳ１１４までの処理において、閾値ρ以上の規則性ＲｏＩＭが有り、且つ閾値μ以上の偏りＢｏＲＭが有ると判定された場合、推定部２５は、対象通信を、Ｃ＆Ｃ通信であると推定し、対象通信を行なっている端末をＣ＆Ｃ通信フェーズで活動するマルウェアに感染した端末として分類（マッピング）する。その後、本フローチャートに示された処理は終了する。
【0046】
図６は、本実施形態に係るＣ＆Ｃ通信検出処理（ＳＳＬ／ＴＬＳ）の流れの概要を示すフローチャートである。本フローチャートは、図４のステップＳ６に示された処理の詳細を説明するものである。本フローチャートに示された処理は、新たなＳＳＬ／ＴＬＳ通信が受信される毎に実行される。
【0047】
ステップＳ２０１からステップＳ２０６では、受信された通信が分析の対象となる通信であるか否かが判定される。新たなＳＳＬ／ＴＬＳ通信（以下、「対象通信」と称する）のデータが取得されると、情報処理装置は、対象通信と同一の通信先に関して蓄積されている過去通信データを取得する（ステップＳ２０１）。ここで、新たに取得された対象通信が、ＣｌｉｅｎｔＨｅｌｌｏメッセージであるがブラウザによる通信である場合（ステップＳ２０２のＹＥＳ且つステップＳ２０３のＹＥＳ）、情報処理装置は、当該通信に係るトランザクションを検査対象から除外する（ステップＳ２０４）。一方、対象通信が、ＣｌｉｅｎｔＨｅｌｌｏメッセージであり且つブラウザによる通信でない場合（ステップＳ２０２のＹＥＳ且つステップＳ２０３のＮＯ）、情報処理装置は、当該通信に係るトランザクションを、ＣｌｉｅｎｔＨｅｌｌｏメッセージ受信済みのトランザクションとして記録する（ステップＳ２０５）。その後、本フローチャートに示された処理は終了し、次のＳＳＬ／ＴＬＳ通信の受信が待たれる。
【0048】
対象通信が、ＳｅｒｖｅｒＨｅｌｌｏメッセージであり且つＣｌｉｅｎｔＨｅｌｌｏメッセージ受信済みのトランザクションに係るものである場合（ステップＳ２０２のＮＯ且つステップＳ２０６のＹＥＳ）、処理はステップＳ２０７へ進む。その他の場合、本フローチャートに示された処理は終了する。
【0049】
ステップＳ２０７からステップＳ２０９では、ＣｌｉｅｎｔＨｅｌｌｏメッセージ及びＳｅｒｖｅｒＨｅｌｌｏメッセージを受信済みの分布分析対象トランザクションが所定数以上検出されたか否かが判定される。ここでは、分布分析対象トランザクションの累積数ＮＣＨが１加算され（ステップＳ２０７）、分布分析対象トランザクションの累積数ＮＣＨが、分布分析に適した所定数σに達したか否かが判定される（ステップＳ２０８）。なお、本実施形態において、下付き文字「ＣＨ」はＳＳＬ／ＴＬＳ通信のＣｌｉｅｎｔＨｅｌｌｏを表す。累積数ＮＣＨが所定数σに達していない場合、対象通信のデータは過去通信データとして蓄積され（ステップＳ２０９）、本フローチャートに示された処理は終了する。一方、累積数ＮＣＨが所定数σに達した場合、処理はステップＳ２１０へ進む。
【0050】
ステップＳ２１０からステップＳ２１２では、通信タイミングの規則性（例えば、周期性）が分析される。分布算出部２４は、複数の通信がＳＳＬ／ＴＬＳ通信である場合に、単一の宛先へのＣｌｉｅｎｔＨｅｌｌｏメッセージと当該ＣｌｉｅｎｔＨｅｌｌｏメッセージの直後のＣｌｉｅｎｔＨｅｌｌｏメッセージとの間隔について、分布（ここでは、通信タイミングの規則性）を算出する（ステップＳ２１０）。規則性の具体的な分析方法については、後述する。
【0051】
推定部２５は、分析の結果算出された規則性ＲｏＩＳを、Ｃ＆Ｃ通信であると推定可能な規則性の有無を判定するための閾値ρと比較する（ステップＳ２１１）。比較の結果、規則性ＲｏＩＳが閾値ρ未満である場合、蓄積された通信のタイミングにＣ＆Ｃ通信であると推定可能な規則性はないと判定され、情報処理装置は、対象通信と同一の通信先に関して蓄積されている過去通信データを削除する（ステップＳ２１２）。その後、本フローチャートに示された処理は終了する。一方、比較の結果、規則性ＲｏＩＳが閾値ρ以上である場合、蓄積された通信のタイミングにＣ＆Ｃ通信であると推定可能な規則性があると判定され、処理はステップＳ２１３へ進む。
【0052】
ステップＳ２１３及びステップＳ２１４では、通信のデータサイズの偏りが分析される。分布算出部２４は、所定サイズ以上のレスポンスを除く、単一の宛先へのレスポンスに係るデータ長について、分布（ここでは、通信のデータサイズの偏り）を算出する（ステップＳ２１３）。なお、所定サイズ以上のレスポンスを除く理由は、所定サイズ以上のレスポンスは、実行ファイルのダウンロードである可能性があり、Ｃ＆Ｃ通信の分布を分析する際にノイズとなるためである。サイズに基づいて実行ファイルのダウンロードを除外する方法は、本実施形態のように、ＳＳＬ／ＴＬＳ通信等の暗号通信でどのようなレスポンスであるか内容が見られない場合に特に有用である。データサイズの偏りの具体的な分析方法については、後述する。
【0053】
推定部２５は、分析の結果算出された偏りＢｏＲＳを、Ｃ＆Ｃ通信であると推定可能な偏りの有無を判定するための閾値μと比較する（ステップＳ２１４）。比較の結果、偏りＢｏＲＳが閾値μ未満である場合、蓄積された通信のデータサイズにＣ＆Ｃ通信であると推定可能な偏りはないと判定され、処理はステップＳ２１２へ進む。一方、比較の結果、偏りＢｏＲＳが閾値μ以上である場合、蓄積された通信のデータサイズにＣ＆Ｃ通信であると推定可能な偏りがあると判定され、処理はステップＳ２１５へ進む。
【0054】
ステップＳ２１５では、対象通信がＣ＆Ｃ通信であると推定される。ステップＳ２１０からステップＳ２１４までの処理において、閾値ρ以上の規則性ＲｏＩＳが有り、且つ閾値μ以上の偏りＢｏＲＳが有ると判定された場合、推定部２５は、対象通信を、Ｃ＆Ｃ通信であると推定し、対象通信を行なっている端末をＣ＆Ｃ通信フェーズで活動するマルウェアに感染した端末として分類（マッピング）する。その後、本フローチャートに示された処理は終了する。
【0055】
図７は、本実施形態に係る感染範囲推定処理（ＨＴＴＰ）の流れの概要を示すフローチャートである。本フローチャートは、図４のステップＳ９に示された処理の詳細を説明するものである。本フローチャートに示された処理は、前述したＣ＆Ｃ通信検出処理で新たなＨＴＴＰのＣ＆Ｃ通信が検出される毎に実行される。なお、以下に説明するフローチャートにおいて、新たにＣ＆Ｃ通信が検出された端末を、「端末Ｈｉ」とする。
【0056】
ステップＳ３０１及びステップＳ３０２では、繰り返し処理の制御が行われる。情報処理装置は、処理対象の既知のＣ＆ＣサーバーＣＣ（Ｈ）ｊを示すためのサーバーインデックスｊに初期値１を設定する（ステップＳ３０１）。その後、サーバーインデックスｊが既知のＣ＆Ｃサーバー数を超えるまで（ステップＳ３０２）、ステップＳ３０２からステップＳ３０８の処理が繰り返し実行される。
【0057】
ステップＳ３０３及びステップＳ３０４では、類似度が算出される。情報処理装置は、既知のＣ＆ＣサーバーＣＣ（Ｈ）ｊに関して蓄積されている過去通信データを取得する（ステップＳ３０３）。そして、類似度算出部２３は、端末ＨｉのＣ＆Ｃ通信（推定部２５によってマルウェアによる通信であると推定された第一の通信）と、既知のＣ＆ＣサーバーＣＣ（Ｈ）ｊについて記録されているＣ＆Ｃ通信（第一の通信を行った端末とは異なる第二の端末による第二の通信）との類似度ＳＩＭＴＬＳ（Ｙ（Ｈｉ），Ｘ（Ｈ）ｉ）を算出する（ステップＳ３０４）。類似度の具体的な算出方法については、後述する。その後、処理はステップＳ３０５へ進む。
【0058】
ステップＳ３０５からステップＳ３０８では、新たにＣ＆Ｃ通信が検出された端末Ｈｉに感染したマルウェアが、既知のＣ＆ＣサーバーＣＣ（Ｈ）ｊのマルウェアと同種のマルウェアであるか否かが判定される。推定部２５は、ステップＳ３０４で算出された類似度が、所定値∂より大であるか否かを判定する（ステップＳ３０５）。また、推定部２５は、新たにＣ＆Ｃ通信が検出された端末ＨｉのＣ＆Ｃサーバーと既知のＣ＆ＣサーバーＣＣ（Ｈ）ｊとが共通するか否かを判定する（ステップＳ３０６）。類似度が所定値∂より大であるか、又は端末ＨｉのＣ＆Ｃサーバーと既知のＣ＆ＣサーバーＣＣ（Ｈ）ｊとが共通する場合、推定部２５は、端末Ｈｉを、既知のＣ＆ＣサーバーＣＣ（Ｈ）ｊのマルウェアと同種のマルウェアに感染していると推定し、当該端末を感染端末候補として記録する（ステップＳ３０７）。その後、サーバーインデックスｊに１加算され（ステップＳ３０８）、処理はステップＳ３０２へ戻る。
【0059】
ステップＳ３０２で、サーバーインデックスｊが既知のＣ＆Ｃサーバー数を超えたと判定されると、処理はステップＳ３０９へ進む。情報処理装置は、記録された感染端末候補を、画面に出力する等することで、ユーザーにマルウェアの推定感染範囲を通知する（ステップＳ３０９）。その後、本フローチャートに示された処理は終了する。
【0060】
なお、図４のステップＳ１０に示された感染範囲推定処理（ＳＳＬ／ＴＬＳ）の流れは、前述したＣ＆Ｃ通信検出処理で新たなＳＳＬ／ＴＬＳのＣ＆Ｃ通信が検出される毎に実行される点、及び類似度評価の対象がＨＴＴＰリクエストトランザクションではなくＳＳＬ／ＴＬＳトランザクションである点を除いて、図７を用いて説明した感染範囲推定処理（ＨＴＴＰ）の流れと概略同様であるため、説明を省略する。また、具体的な類似度の算出方法については、後述する。
【0061】
図８は、本実施形態に係るマルウェア・ファミリー推定処理（ＨＴＴＰ）の流れの概要を示すフローチャートである。本フローチャートは、図４のステップＳ１１に示された処理の詳細を説明するものである。本フローチャートに示された処理は、前述したＣ＆Ｃ通信検出処理で新たなＨＴＴＰのＣ＆Ｃ通信が検出される毎に実行される。また、本フローチャートに示された処理は、ユーザーによる、マルウェア・ファミリー推定の対象となるＨＴＴＰ通信の選択及び推定処理開始の指示が受け付けられたことを契機として開始されてもよい。
【0062】
ステップＳ４０１及びステップＳ４０２では、マルウェア・ファミリー推定の対象となる通信と、マルウェア通信データベース（マルウェアによる通信データ及び／又はマルウェアによる通信データの特徴データが蓄積されている）に蓄積された複数のマルウェア通信夫々との類似度のうち、最大の類似度が取得される。類似度算出部２３は、マルウェア・ファミリー推定の対象となる通信（推定部２５によってマルウェアによる通信であると推定された第一の通信）と、マルウェア通信データベースに蓄積された複数の（例えば、全ての）マルウェア通信（既知のソフトウェアによる既知の通信）夫々との類似度を計算する（ステップＳ４０１）。具体的な類似度の算出方法については、後述する。そして、情報処理装置は、算出された、マルウェア・ファミリー推定の対象となる通信と、マルウェア通信データベースに蓄積された複数のマルウェア通信夫々との類似度のうち、最大の類似度を、類似度ＳＩＭＨＴＴＰ（Ｙ（β），Ｘ（α））として記録する（ステップＳ４０２）。その後、処理はステップＳ４０３へ進む。
【0063】
ステップＳ４０３からステップＳ４０７では、マルウェア・ファミリーが推定される。推定部２５は、ステップＳ４０２で得られた最大の類似度ＳＩＭＨＴＴＰを、同種であると推定するための閾値Ａ及び亜種であると推定するための閾値Ｂ（ここで、閾値Ａ＞閾値Ｂ）と比較することで（ステップＳ４０３及びステップＳ４０５）、マルウェア・ファミリー推定の対象となる通信に係るマルウェアが、最大の類似度ＳＩＭＨＴＴＰを有する既知のマルウェアの同種であるか、亜種であるか、又は別種であるかを推定する。具体的には、推定部２５は、最大の類似度ＳＩＭＨＴＴＰが閾値Ａより大である場合、対象通信のマルウェアが、最大の類似度ＳＩＭＨＴＴＰを有する既知のマルウェアの同種であると推定する（ステップＳ４０４）。また、推定部２５は、最大の類似度ＳＩＭＨＴＴＰが閾値Ａ以下であり且つ閾値Ｂより大である場合、対象通信のマルウェアが、最大の類似度ＳＩＭＨＴＴＰを有する既知のマルウェアの亜種であると推定する（ステップＳ４０６）。そして、推定部２５は、最大の類似度ＳＩＭＨＴＴＰが閾値Ｂ以下である場合、対象通信のマルウェアが、最大の類似度ＳＩＭＨＴＴＰを有する既知のマルウェアと別種であると推定する（ステップＳ４０７）。情報処理装置は、推定結果を、画面に出力する等することで、ユーザーに通知してもよい。その後、本フローチャートに示された処理は終了する。
【0064】
なお、図４のステップＳ１２に示されたマルウェア・ファミリー推定処理（ＳＳＬ／ＴＬＳ）の流れは、前述したＣ＆Ｃ通信検出処理で新たなＳＳＬ／ＴＬＳのＣ＆Ｃ通信が検出される毎に実行される点、ユーザーによる、マルウェア・ファミリー推定の対象となるＳＳＬ／ＴＬＳ通信の選択及び推定処理開始の指示が受け付けられたことを契機として開始されてもよい点、及び類似度評価の対象がＨＴＴＰリクエストパケットではなくＳＳＬ／ＴＬＳトランザクションである点を除いて、図８を用いて説明したマルウェア・ファミリー推定処理（ＨＴＴＰ）の流れと概略同様であるため、説明を省略する。また、具体的な類似度の算出方法については、後述する。
【0065】
＜ＨＴＴＰ通信の構造的な類似度＞
ここで、対象通信がＨＴＴＰ通信である場合の類似度の具体的な算出方法について説明する。本実施形態では、ＨＴＴＰ通信の場合、ＧＥＴメソッド、ＰＯＳＴ／ＰＵＴメソッド毎にＨＴＴＰリクエストヘッダーの以下に示す要素について要素類似度を算出し、最終的な総合類似度ＳＩＭ（Ｘ，Ｙ）を算出する。ここで、Ｘ及びＹはＨＴＴＰリクエストを示す。
ここで、対象通信がＨＴＴＰ通信である場合の類似度の具体的な算出方法について説明する。本実施形態では、ＨＴＴＰ通信の場合、ＧＥＴメソッド、ＰＯＳＴ／ＰＵＴメソッド毎にＨＴＴＰリクエストヘッダーの以下に示す要素について要素類似度を算出し、最終的な総合類似度ＳＩＭ（Ｘ，Ｙ）を算出する。ここで、Ｘ及びＹはＨＴＴＰリクエストを示す。
【0066】
＜＜ＨＴＴＰリクエストライン形式の類似度Ｓｒ＞＞
類似度算出部２３は、リクエストラインを所定のルールで抽象化した集合ＲＬで表し、ある２つのリクエストＸ、Ｙについて以下の式を用いることで、リクエストラインからメソッドを除いたＵＲＩとＨＴＴＰバージョンの類似度Ｓｒを算出する。なお、ここで、「Ｊａｃ（）」は、Ｊａｃｃａｒｄ係数の算出関数であり、集合に含まれる要素の共通度を表す。
Sr(X, Y) = Jac(RL(X), RL(Y))
類似度算出部２３は、リクエストラインを所定のルールで抽象化した集合ＲＬで表し、ある２つのリクエストＸ、Ｙについて以下の式を用いることで、リクエストラインからメソッドを除いたＵＲＩとＨＴＴＰバージョンの類似度Ｓｒを算出する。なお、ここで、「Ｊａｃ（）」は、Ｊａｃｃａｒｄ係数の算出関数であり、集合に含まれる要素の共通度を表す。
Sr(X, Y) = Jac(RL(X), RL(Y))
【0067】
＜＜ＨＴＴＰリクエストヘッダーの種類の類似度Ｓｎ＞＞
類似度算出部２３は、リクエストヘッダー名を変換テーブルに従って変換することで、リクエストヘッダーの種類の集合Ｈｎ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて以下の式を用いることで、リクエストヘッダーに含まれるリクエストヘッダーの種類の類似度Ｓｎを算出する。本実施形態において、不明なリクエストヘッダーは「未知のリクエストヘッダー」として扱うこととする。
Sn(X, Y) = Jac(Hn(X), Hn(Y))
類似度算出部２３は、リクエストヘッダー名を変換テーブルに従って変換することで、リクエストヘッダーの種類の集合Ｈｎ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて以下の式を用いることで、リクエストヘッダーに含まれるリクエストヘッダーの種類の類似度Ｓｎを算出する。本実施形態において、不明なリクエストヘッダーは「未知のリクエストヘッダー」として扱うこととする。
Sn(X, Y) = Jac(Hn(X), Hn(Y))
【0068】
＜＜ＨＴＴＰリクエストヘッダーの並びの類似度Ｓｏ＞＞
類似度算出部２３は、リクエストヘッダー名を変換テーブルに従って変換することで、リクエストヘッダーの並びを抽象化した文字列Ｈｏ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて、リクエストヘッダーに含まれるリクエストヘッダーの種類の並び順の類似度Ｓｏを算出する。本実施形態において、不明なリクエストヘッダーは「未知のリクエストヘッダー」として扱うこととする。ここで、「ＮＤＬ（）」は、標準化Ｄａｍｅｒａｕ－Ｌｅｖｅｎｓｈｔｅｉｎ距離であり、文字列の類似度を表す。｜Ｋ｜及び｜Ｌ｜は、文字列Ｋ及びＬの長さ（文字数）を示す。
So(X, Y) = NDL(Ho(X), Ho(Y))
NDL(K, L) = 1.0 － DL(K, L) / max(|K|, |L|)
DL(K, L)：K,LのDamerau-Levenshtein距離
類似度算出部２３は、リクエストヘッダー名を変換テーブルに従って変換することで、リクエストヘッダーの並びを抽象化した文字列Ｈｏ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて、リクエストヘッダーに含まれるリクエストヘッダーの種類の並び順の類似度Ｓｏを算出する。本実施形態において、不明なリクエストヘッダーは「未知のリクエストヘッダー」として扱うこととする。ここで、「ＮＤＬ（）」は、標準化Ｄａｍｅｒａｕ－Ｌｅｖｅｎｓｈｔｅｉｎ距離であり、文字列の類似度を表す。｜Ｋ｜及び｜Ｌ｜は、文字列Ｋ及びＬの長さ（文字数）を示す。
So(X, Y) = NDL(Ho(X), Ho(Y))
NDL(K, L) = 1.0 － DL(K, L) / max(|K|, |L|)
DL(K, L)：K,LのDamerau-Levenshtein距離
【0069】
なお、本実施形態では、Ｐｒｏｘｙ環境で利用されるヘッダー（例えば、「Forwarded」、「Max-Forwards」、「Proxy-Authorization」、「Via」、「Warning」、「X-Forwarded-For」等）が設定されている場合、そのヘッダーは無視される（設定されていないものと見做す）。また、リクエストヘッダーの名前は、大文字小文字を区別せずに判定して、リクエストヘッダー毎にあらかじめ設定された記号に置換される（例えば、「Accept:」は「A」に置換、「Content-Length:」は「L」に置換、等）。
【0070】
＜＜主要なリクエストヘッダーの値の類似度Ｓｖ＞＞
類似度算出部２３は、主要なリクエストヘッダーの値を変換テーブルに従って変換することで抽象化した集合Ｈｖ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて以下の式を用いることで、共通する主要なリクエストヘッダーに関して、主要なリクエストヘッダーに設定されている値をルールに従って抽象化したときの類似度Ｓｖを算出する。
Sv(X, Y) = Jac(Hv(X), Hv(Y))
類似度算出部２３は、主要なリクエストヘッダーの値を変換テーブルに従って変換することで抽象化した集合Ｈｖ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて以下の式を用いることで、共通する主要なリクエストヘッダーに関して、主要なリクエストヘッダーに設定されている値をルールに従って抽象化したときの類似度Ｓｖを算出する。
Sv(X, Y) = Jac(Hv(X), Hv(Y))
【0071】
＜＜リクエストＵＲＩのクエリパラメタの類似度Ｓｐ＞＞
類似度算出部２３は、リクエストラインのクエリ部のパラメタのｋｅｙ値を抽出することで集合Ｐｒ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて以下の式を用いることで、リクエストＵＲＩのクエリ部のパラメタ群の種類の類似度Ｓｐを算出する。
Sp(X, Y) = Jac(Pr(X), Pr(Y))
類似度算出部２３は、リクエストラインのクエリ部のパラメタのｋｅｙ値を抽出することで集合Ｐｒ（Ｘ）を準備し、ある２つのリクエストＸ，Ｙについて以下の式を用いることで、リクエストＵＲＩのクエリ部のパラメタ群の種類の類似度Ｓｐを算出する。
Sp(X, Y) = Jac(Pr(X), Pr(Y))
【0072】
＜＜ＨＴＴＰ通信の総合類似度ＳＩＭＨＴＴＰ＞＞
そして、類似度算出部２３は、算出された各類似度を要素類似度として要素毎に重み付け（重み係数：ωｒ、ωｎ、ωｏ、ωｖ、ωｐ）し、合計することで、総合類似度ＳＩＭＨＴＴＰ（Ｘ，Ｙ）を算出する。なお、本実施形態において、総合類似度ＳＩＭＨＴＴＰ（Ｘ，Ｙ）は所定の範囲（例えば、０以上１．０以下）内の値に正規化される。
SIMHTTP(X, Y) = ωr・Sr(X, Y)+ωn・Sn(X, Y)+ωo・So(X, Y)+ωv・Sv(X, Y)+ωp・Sp(X, Y)
そして、類似度算出部２３は、算出された各類似度を要素類似度として要素毎に重み付け（重み係数：ωｒ、ωｎ、ωｏ、ωｖ、ωｐ）し、合計することで、総合類似度ＳＩＭＨＴＴＰ（Ｘ，Ｙ）を算出する。なお、本実施形態において、総合類似度ＳＩＭＨＴＴＰ（Ｘ，Ｙ）は所定の範囲（例えば、０以上１．０以下）内の値に正規化される。
SIMHTTP(X, Y) = ωr・Sr(X, Y)+ωn・Sn(X, Y)+ωo・So(X, Y)+ωv・Sv(X, Y)+ωp・Sp(X, Y)
【0073】
＜ＳＳＬ／ＴＬＳ通信の構造的な類似度＞
次に、対象通信がＳＳＬ／ＴＬＳ通信である場合の類似度の具体的な算出方法について説明する。本実施形態では、ＳＳＬ／ＴＬＳ通信の場合、「（ＴＣＰコネクションの確立）→ＳＳＬ／ＴＬＳネゴシエーション→ＳＳＬ／ＴＬＳセッション上でのデータ送受信→（ＴＣＰコネクションの解放）」の一連のトラフィックをＳＳＬ／ＴＬＳトランザクションと定義し、トランザクション毎の類似性を判定する。
次に、対象通信がＳＳＬ／ＴＬＳ通信である場合の類似度の具体的な算出方法について説明する。本実施形態では、ＳＳＬ／ＴＬＳ通信の場合、「（ＴＣＰコネクションの確立）→ＳＳＬ／ＴＬＳネゴシエーション→ＳＳＬ／ＴＬＳセッション上でのデータ送受信→（ＴＣＰコネクションの解放）」の一連のトラフィックをＳＳＬ／ＴＬＳトランザクションと定義し、トランザクション毎の類似性を判定する。
【0074】
＜＜ＣｌｉｅｎｔＨｅｌｌｏメッセージのフィンガープリントの類似度ＴＳＣＨＦＰ＞＞
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳの開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージのフィンガープリントの類似度を算出することで、ＴＬＳのバージョンや暗号化アルゴリズムのリスト等を比較する。これは、様々なマルウェアが送信するＣｌｉｅｎｔＨｅｌｌｏメッセージのプロトコル要素には微妙に差異があり、ＣｌｉｅｎｔＨｅｌｌｏメッセージのプロトコル要素は、マルウェアを特定するための特徴量の一つになるためである。具体的には、本実施形態では、ＳＳＬ／ＴＬＳトランザクションＳとＴの開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージの類似度ＴＳｃｈｆｐ（Ｓ，Ｔ）を、フィンガープリントが一致する場合には「１」を出力し、フィンガープリントが異なる場合には「０」を出力する二値関数を用いて算出する。
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳの開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージのフィンガープリントの類似度を算出することで、ＴＬＳのバージョンや暗号化アルゴリズムのリスト等を比較する。これは、様々なマルウェアが送信するＣｌｉｅｎｔＨｅｌｌｏメッセージのプロトコル要素には微妙に差異があり、ＣｌｉｅｎｔＨｅｌｌｏメッセージのプロトコル要素は、マルウェアを特定するための特徴量の一つになるためである。具体的には、本実施形態では、ＳＳＬ／ＴＬＳトランザクションＳとＴの開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージの類似度ＴＳｃｈｆｐ（Ｓ，Ｔ）を、フィンガープリントが一致する場合には「１」を出力し、フィンガープリントが異なる場合には「０」を出力する二値関数を用いて算出する。
【0075】
＜＜ＣｌｉｅｎｔＨｅｌｌｏのＳＮＩの類似度ＴＳＣＳＮＩ＞＞
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳの開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージのＳＮＩ（サーバー名）の類似度を算出する。具体的には、本実施形態では、ＣｌｉｅｎｔＨｅｌｌｏのＳＮＩの類似度ＴＳＣＳＮＩ（Ｓ，Ｔ）を、ＳＳＬ／ＴＬＳトランザクションＳとＴのＳＮＩが一致し且つトランザクションＳのＳＮＩがＮＵＬＬでない場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数を用いて算出する。
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳの開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージのＳＮＩ（サーバー名）の類似度を算出する。具体的には、本実施形態では、ＣｌｉｅｎｔＨｅｌｌｏのＳＮＩの類似度ＴＳＣＳＮＩ（Ｓ，Ｔ）を、ＳＳＬ／ＴＬＳトランザクションＳとＴのＳＮＩが一致し且つトランザクションＳのＳＮＩがＮＵＬＬでない場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数を用いて算出する。
【0076】
＜＜リクエストサイズのパターン数の類似度ＴＳＮＯＳＰ＞＞
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳｉ（ｉ＝１．．．）とトランザクションＴｊ（ｊ＝１．．．）のリクエストサイズのパターン数の類似度ＴＳｎｏｓｐ（Ｓ，Ｔ）を、以下に説明する分類によってトランザクションＳｉ（ｉ＝１．．．）が分類されたクラスの数とトランザクションＴｊ（ｊ＝１．．．）が分類されたクラスの数とが一致する場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数で定義する。
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳｉ（ｉ＝１．．．）とトランザクションＴｊ（ｊ＝１．．．）のリクエストサイズのパターン数の類似度ＴＳｎｏｓｐ（Ｓ，Ｔ）を、以下に説明する分類によってトランザクションＳｉ（ｉ＝１．．．）が分類されたクラスの数とトランザクションＴｊ（ｊ＝１．．．）が分類されたクラスの数とが一致する場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数で定義する。
【0077】
ここで、トランザクションの分類は、具体的には、例えば以下の手順で、同一のクライアントとサーバ間で送受信される複数のＳＳＬ／ＴＬＳトランザクションＳｊ（ｊ＝１．．）を対象に、クライアントからサーバに向けて送信される最初のリクエストパケットのサイズの傾向を分析することで行われる。
・１５個のＳＳＬ／ＴＬＳトランザクションＳｊ（ｊ＝１．．１５）に対して、ＳＳＬ／ＴＬＳネゴシエーション完了後、クライアントからサーバ向けに送信される最初のＡｐｐｌｉｃａｔｉｏｎＤａｔａのデータ長Ｒｊを計測する。ここで、計測したデータ長の集合をＲｅｑＳｉｚｅ＝｛Ｒ１，Ｒ２，Ｒ３，．．．Ｒ１４，Ｒ１５｝とする。
・データ長の集合ＲｅｑＳｉｚｅを近似値（±１０％）でｎ個の互いに素なクラスＣｎに分類する。
・上記の手順で求めた互いに素なクラスＣｎのうち、｜Ｃｎ｜≧３を満たすクラスＣｎの個数ｍをリクエストサイズのパターン数ＮｏＳＰ（Ｎｕｍｂｅｒ ｏｆ ｒｅｑｕｅｓｔ Ｓｉｚｅ Ｐａｔｔｅｒｎｓ）と定義する。ここで、｜Ｃｎ｜≧３を満たすクラスのみに限定しているのは、偶然発生したクラスを除外するためである。
・上記のｍ個のクラスＣｋ（ｋ＝１．．ｍ）に属すデータ長Ｒｊの平均値Ａｖｇ（Ｃｋ）の集合をパターンの平均リクエストサイズＡｏＳＰ（Ａｖｅｒａｇｅ ｏｆ ｒｅｑｕｅｓｔ Ｓｉｚｅ Ｐａｔｔｅｒｎｓ）と定義する。
・１５個のＳＳＬ／ＴＬＳトランザクションＳｊ（ｊ＝１．．１５）に対して、ＳＳＬ／ＴＬＳネゴシエーション完了後、クライアントからサーバ向けに送信される最初のＡｐｐｌｉｃａｔｉｏｎＤａｔａのデータ長Ｒｊを計測する。ここで、計測したデータ長の集合をＲｅｑＳｉｚｅ＝｛Ｒ１，Ｒ２，Ｒ３，．．．Ｒ１４，Ｒ１５｝とする。
・データ長の集合ＲｅｑＳｉｚｅを近似値（±１０％）でｎ個の互いに素なクラスＣｎに分類する。
・上記の手順で求めた互いに素なクラスＣｎのうち、｜Ｃｎ｜≧３を満たすクラスＣｎの個数ｍをリクエストサイズのパターン数ＮｏＳＰ（Ｎｕｍｂｅｒ ｏｆ ｒｅｑｕｅｓｔ Ｓｉｚｅ Ｐａｔｔｅｒｎｓ）と定義する。ここで、｜Ｃｎ｜≧３を満たすクラスのみに限定しているのは、偶然発生したクラスを除外するためである。
・上記のｍ個のクラスＣｋ（ｋ＝１．．ｍ）に属すデータ長Ｒｊの平均値Ａｖｇ（Ｃｋ）の集合をパターンの平均リクエストサイズＡｏＳＰ（Ａｖｅｒａｇｅ ｏｆ ｒｅｑｕｅｓｔ Ｓｉｚｅ Ｐａｔｔｅｒｎｓ）と定義する。
【0078】
一般に、マルウェアが送信するリクエストパケットの形式は固定化（＝リクエストサイズが固定）されていることが多い。したがって、ＮｏＳＰ（Ｓ）の値は、リクエスト形式の種類（ＧＥＴ、ＰＯＳＴ／ＰＵＴなど）に対応するため、マルウェアを特定するための特徴量の一つになる。例えば、ＨＴＴＰＳベースのマルウェアがＮｏＳＰ（Ｓ）＝２の場合、ＧＥＴとＰＯＳＴ／ＰＵＴメソッドの両方を使用している可能性が高いと推定できる。
【0079】
＜＜送信間隔の周期数の類似度ＴＳＮＯＩＣ＞＞
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳｉ（ｉ＝１．．．）とトランザクションＴｊ（ｊ＝１．．．）の開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔の周期数の類似度ＴＳｎｏｉｃ（Ｓ，Ｔ）を、送信間隔の周期数ＮｏＩＣ（Ｎｕｍｂｅｒ ｏｆ Ｉｎｔｅｒｖａｌ Ｃｙｃｌｅｓ）が一致する場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数で定義する。
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳｉ（ｉ＝１．．．）とトランザクションＴｊ（ｊ＝１．．．）の開始時に送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔の周期数の類似度ＴＳｎｏｉｃ（Ｓ，Ｔ）を、送信間隔の周期数ＮｏＩＣ（Ｎｕｍｂｅｒ ｏｆ Ｉｎｔｅｒｖａｌ Ｃｙｃｌｅｓ）が一致する場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数で定義する。
【0080】
ここで、トランザクションの分類は、具体的には、例えば以下の手順で、同一のクライアントとサーバ間で送受信される複数のＳＳＬ／ＴＬＳトランザクションＳｊ（ｊ＝１．．）を対象に、個々のＣｌｉｅｎｔＨｅｌｌｏメッセージが送信される送信間隔の周期数の類似度を分析することで行われる。
・下記の条件を満たすＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔のクラスＣｎの個数を送信間隔の周期数ＮｏＩＣと定義する。なお、下記の条件を満たす送信間隔のクラスＣｎに属する値の平均値＜Ｃｎ＞が個々の周期値を示す。
NoIC(S) = |{Cn | RoIS(Cn)=|Tol(Cn)|/ |Cn|≧ρ,∀|Cn|≧4}|
・下記の条件を満たすＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔のクラスＣｎの個数を送信間隔の周期数ＮｏＩＣと定義する。なお、下記の条件を満たす送信間隔のクラスＣｎに属する値の平均値＜Ｃｎ＞が個々の周期値を示す。
NoIC(S) = |{Cn | RoIS(Cn)=|Tol(Cn)|/ |Cn|≧ρ,∀|Cn|≧4}|
【0081】
一般に、マルウェアの送信間隔の周期数は、１であるが、周期数が２や３のマルウェアも存在するため、周期数は、マルウェアを特定するための特徴量の一つになる。
【0082】
＜＜ＳＳＬサーバ証明書のタイプの類似度ＴＳＣＴＹＰ＞＞
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳ及びトランザクションＴに含まれる、各々のサーバから送信されるＣｅｒｔｉｆｉｃａｔｅメッセージに含まれるＳＳＬサーバ証明書のタイプの類似度ＴＳｃｔｙｐ（Ｓ，Ｔ）を、ＣｅｒｔｉｆｉｃａｔｅメッセージのＳＳＬサーバ証明書のタイプＣｅｒｔＴｙｐｅ（Ｓ）とＣｅｒｔＴｙｐｅ（Ｔ）とが一致する場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数で定義する。具体的には、類似度算出部２３は、サーバから送信されるＣｅｒｔｉｆｉｃａｔｅメッセージのＳＳＬサーバ証明書のタイプ（正当なＣＡ証明書、自己署名証明書、証明書無し、等）の一致性を比較する。攻撃者は、攻撃基盤を構築するにあたり、複数台のＣ＆Ｃサーバ（または、Ｃ＆Ｃ中継サーバ）を配置するケースが多いが、殆どのケースで同じタイプのＳＳＬサーバ証明書が使用されていることから、Ｃ＆Ｃサーバに対応するマルウェアを特定するための特徴量の一つになる。
類似度算出部２３は、ＳＳＬ／ＴＬＳトランザクションＳ及びトランザクションＴに含まれる、各々のサーバから送信されるＣｅｒｔｉｆｉｃａｔｅメッセージに含まれるＳＳＬサーバ証明書のタイプの類似度ＴＳｃｔｙｐ（Ｓ，Ｔ）を、ＣｅｒｔｉｆｉｃａｔｅメッセージのＳＳＬサーバ証明書のタイプＣｅｒｔＴｙｐｅ（Ｓ）とＣｅｒｔＴｙｐｅ（Ｔ）とが一致する場合には「１」を出力し、それ以外の場合には「０」を出力する二値関数で定義する。具体的には、類似度算出部２３は、サーバから送信されるＣｅｒｔｉｆｉｃａｔｅメッセージのＳＳＬサーバ証明書のタイプ（正当なＣＡ証明書、自己署名証明書、証明書無し、等）の一致性を比較する。攻撃者は、攻撃基盤を構築するにあたり、複数台のＣ＆Ｃサーバ（または、Ｃ＆Ｃ中継サーバ）を配置するケースが多いが、殆どのケースで同じタイプのＳＳＬサーバ証明書が使用されていることから、Ｃ＆Ｃサーバに対応するマルウェアを特定するための特徴量の一つになる。
【0083】
＜＜ＳＳＬ／ＴＬＳ通信の総合類似度ＳＩＭＴＬＳ＞＞
そして、類似度算出部２３は、算出された各類似度を要素類似度として要素毎に重み付け（重み係数：ω１、ω２、ω３、ω４、ω５）し、合計することで、総合類似度ＳＩＭＴＬＳ（Ｘ，Ｙ）を算出する。なお、本実施形態において、総合類似度ＳＩＭＴＬＳ（Ｘ，Ｙ）は所定の範囲内の値に正規化される。
SIMTLS(X, Y) = ω1・TSchfp(X, Y)+ω2・TScsni(X, Y)+ω3・TSnosp(X, Y)+ω4・TSnoic(X, Y)+ω5・TSctyp(X, Y)
そして、類似度算出部２３は、算出された各類似度を要素類似度として要素毎に重み付け（重み係数：ω１、ω２、ω３、ω４、ω５）し、合計することで、総合類似度ＳＩＭＴＬＳ（Ｘ，Ｙ）を算出する。なお、本実施形態において、総合類似度ＳＩＭＴＬＳ（Ｘ，Ｙ）は所定の範囲内の値に正規化される。
SIMTLS(X, Y) = ω1・TSchfp(X, Y)+ω2・TScsni(X, Y)+ω3・TSnosp(X, Y)+ω4・TSnoic(X, Y)+ω5・TSctyp(X, Y)
【0084】
＜通信タイミングの規則性＞
本実施形態では、上記フローチャートで説明した通り、ネットワーク上で送受信されるリクエスト通信が集められ、この際、送受信された通信について、通信のタイミング（本実施形態では、送信間隔）が記録される。具体的には、ＨＴＴＰ通信の場合、ある宛先Ｄｓｔに対するＨＴＴＰリクエストのＧＥＴメソッドまたはＰＯＳＴ／ＰＵＴメソッドそれぞれについて、リクエスト送信間隔が求められ、記録される。又、ＳＳＬ／ＴＬＳ通信の場合、ある宛先Ｄｓｔに対するＣｌｉｅｎｔＨｅｌｌｏメッセージと直後のＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔が求められ、記録される。そして、以下に説明する方法で、通信タイミングの規則性が分析される。
本実施形態では、上記フローチャートで説明した通り、ネットワーク上で送受信されるリクエスト通信が集められ、この際、送受信された通信について、通信のタイミング（本実施形態では、送信間隔）が記録される。具体的には、ＨＴＴＰ通信の場合、ある宛先Ｄｓｔに対するＨＴＴＰリクエストのＧＥＴメソッドまたはＰＯＳＴ／ＰＵＴメソッドそれぞれについて、リクエスト送信間隔が求められ、記録される。又、ＳＳＬ／ＴＬＳ通信の場合、ある宛先Ｄｓｔに対するＣｌｉｅｎｔＨｅｌｌｏメッセージと直後のＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔が求められ、記録される。そして、以下に説明する方法で、通信タイミングの規則性が分析される。
【0085】
分布算出部２４は、記録された送信間隔の集合について度数（頻度）分布を分析するために、送信間隔毎のクラス（度数を集計するための区間。Ｃｎ（ｎ＝１，２．．．）で示す）に分割し、規則性（ＲｏＩ：Ｒｅｇｕｌａｒｉｔｙ ｏｆ Ｉｎｔｅｒｖａｌ）を算出する。ここで、度数は、クラスＣｎに含まれる計測データの要素数であり、｜Ｃｎ｜（ｎ＝１，２．．．）で表される。そして、分布算出部２４は、算出された規則性ＲｏＩに基づいて、送信間隔全体で規則性があるか否かを判定する。なお、本実施形態では、分析の対象とするデータの周期の最小値、最大値を閾値としてもち、外れたものを誤差（ごみ）として分析対象外とすることで、分析の精度を向上させることとしている。
【0086】
本実施形態では、以下の手順で、送信間隔（インターバル時間）の規則性ＲｏＩが算出される。本実施形態では、規則性ＲｏＩは、０から１の範囲の値で出力され、１に近いほど規則性があると判定される。
（１）パケットＸｉとＸｉ＋１∈ＴＲ（ＴＲはリクエストの集合）の送信間隔Ｉｉ（ｉ＝１～σ）をσ回計測して記録し、その送信間隔の集合を集合Ｉｎｔｖｌとする。
（２）送信間隔の集合Ｉｎｔｖｌのうち、Ｉｉ＜２５０ｍｓを満たすＩｉを、２５０ｍｓに置換する。（２５０ｍｓ未満の送信間隔は、遅延誤差範囲とみなし、一律、２５０ｍｓとする。）
（３）送信間隔の集合Ｉｎｔｖｌから、最大値Ｍａｘ（Ｉｍ）と最小値Ｍｉｎ（Ｉｎ）を求め、クラス幅（区間）ＫＣを決定する。ここで、クラス数ＮＣ＝１＋３．３２２＊ｌｏｇ１０Ｍ（但し、Ｍ：数値データの総数）とする。最終的なクラス幅（区間）ＫＣは、小数点以下を四捨五入（整数値）して求められる。ＫＣが１以下の場合は、ＫＣ＝１とする。
KC = (Max(Im)+Min(In))/NC
（４）送信間隔の集合Ｉｎｔｖｌに対して、クラス幅ＫＣによって、クラス数ＮＣのクラスＣｎ（ｎ＝１～ＮＣ）に等分割し、計測した送信間隔Ｉｉ∈Ｉｎｔｖｌを適切なクラスに振り分ける。なお、度数｜Ｃｎ｜≦１のＣｎについては、（４）、（５）、（６）の計算は省略されてよい。
（５）クラスＣｎ（ｎ＝１～ＮＣ）毎に、以下の値を計算する。
Avg(Cn) = ΣCn Ii /|Cn| ：Ｉｉ∈Ｃｎに属する送信間隔の平均値（ｍｓｅｃ）
Inf(Cn) = Avg(Cn)*(1―θ) ：Ｃｎに属する送信間隔の許容下限値（平均―許容誤差）（ｍｓｅｃ）
Sup(Cn) = Avg(Cn)*(1+θ) ：Ｃｎに属する送信間隔の許容上限値（平均＋許容誤差）（ｍｓｅｃ）
（６）クラスＣｎ（ｎ＝１～ＮＣ）毎に、許容下限値Ｉｎｆ（Ｃｎ）と許容上限値Ｓｕｐ（Ｃｎ）の範囲内に存在する送信間隔Ｉｉの集合Ｔｏｌ（Ｃｎ）と、集合に含まれる送信間隔Ｉｉの要素数｜Ｔｏｌ（Ｃｎ）｜を求める。
Tol(Cn) = { Ii ∈ Cn | Inf(Cn) ≦ Ii ≦ Sup(Cn) , |Cn| ＞ 0 } , n=1～NC
（７）送信間隔の規則性ＲｏＩを以下の式で定義する。但し、｜Ｃｎ｜＜４のＣｎは、評価対象から除外する。
RoI = min{RoI(Cn) | RoI(Cn)=|Tol(Cn)|/ |Cn| ,∀|Cn|≧4}, 0≦RoI≦1.0
（１）パケットＸｉとＸｉ＋１∈ＴＲ（ＴＲはリクエストの集合）の送信間隔Ｉｉ（ｉ＝１～σ）をσ回計測して記録し、その送信間隔の集合を集合Ｉｎｔｖｌとする。
（２）送信間隔の集合Ｉｎｔｖｌのうち、Ｉｉ＜２５０ｍｓを満たすＩｉを、２５０ｍｓに置換する。（２５０ｍｓ未満の送信間隔は、遅延誤差範囲とみなし、一律、２５０ｍｓとする。）
（３）送信間隔の集合Ｉｎｔｖｌから、最大値Ｍａｘ（Ｉｍ）と最小値Ｍｉｎ（Ｉｎ）を求め、クラス幅（区間）ＫＣを決定する。ここで、クラス数ＮＣ＝１＋３．３２２＊ｌｏｇ１０Ｍ（但し、Ｍ：数値データの総数）とする。最終的なクラス幅（区間）ＫＣは、小数点以下を四捨五入（整数値）して求められる。ＫＣが１以下の場合は、ＫＣ＝１とする。
KC = (Max(Im)+Min(In))/NC
（４）送信間隔の集合Ｉｎｔｖｌに対して、クラス幅ＫＣによって、クラス数ＮＣのクラスＣｎ（ｎ＝１～ＮＣ）に等分割し、計測した送信間隔Ｉｉ∈Ｉｎｔｖｌを適切なクラスに振り分ける。なお、度数｜Ｃｎ｜≦１のＣｎについては、（４）、（５）、（６）の計算は省略されてよい。
（５）クラスＣｎ（ｎ＝１～ＮＣ）毎に、以下の値を計算する。
Avg(Cn) = ΣCn Ii /|Cn| ：Ｉｉ∈Ｃｎに属する送信間隔の平均値（ｍｓｅｃ）
Inf(Cn) = Avg(Cn)*(1―θ) ：Ｃｎに属する送信間隔の許容下限値（平均―許容誤差）（ｍｓｅｃ）
Sup(Cn) = Avg(Cn)*(1+θ) ：Ｃｎに属する送信間隔の許容上限値（平均＋許容誤差）（ｍｓｅｃ）
（６）クラスＣｎ（ｎ＝１～ＮＣ）毎に、許容下限値Ｉｎｆ（Ｃｎ）と許容上限値Ｓｕｐ（Ｃｎ）の範囲内に存在する送信間隔Ｉｉの集合Ｔｏｌ（Ｃｎ）と、集合に含まれる送信間隔Ｉｉの要素数｜Ｔｏｌ（Ｃｎ）｜を求める。
Tol(Cn) = { Ii ∈ Cn | Inf(Cn) ≦ Ii ≦ Sup(Cn) , |Cn| ＞ 0 } , n=1～NC
（７）送信間隔の規則性ＲｏＩを以下の式で定義する。但し、｜Ｃｎ｜＜４のＣｎは、評価対象から除外する。
RoI = min{RoI(Cn) | RoI(Cn)=|Tol(Cn)|/ |Cn| ,∀|Cn|≧4}, 0≦RoI≦1.0
【0087】
＜通信データサイズの偏り＞
本実施形態では、上記フローチャートで説明した通り、ネットワーク上で送受信されるリクエスト通信が集められ、この際、送受信された通信について、データサイズが記録される。具体的には、ＨＴＴＰ通信の場合、ある宛先Ｄｓｔに対するＨＴＴＰレスポンスについて、ＧＥＴメソッド、ＰＯＳＴ／ＰＵＴメソッド毎にヘッダー部を除いたデータ長が記録される。但し、レスポンスデータを検査することで、実行ファイルをＤＬしたと疑われる通信は除外される。また、ＳＳＬ／ＴＬＳ通信の場合、ある宛先Ｄｓｔに対するＳＳＬ／ＴＬＳトランザクションのＣｌｉｅｎｔからＳｅｒｖｅｒ向きのＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａ（ＣｔｏＳ）をリクエストデータとし、その直後のＳｅｒｖｅｒからＣｌｉｅｎｔ向きのＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａ（ＳｔｏＣ）をレスポンスデータとして、レスポンスデータそれぞれのＬｅｎｇｔｈフィールド値の合算値が記録される。なお、本実施形態では、途中にＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージ（ＣｔｏＳ）が割り込まない連続した一連のＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージ（ＳｔｏＣ）をレスポンスデータと見做し、そのＬｅｎｇｔｈフィールド値の合算値をレスポンスデータ長とするが、レスポンスデータ長が６５５３６（６４Ｋ）バイト以上である場合は、当該レスポンスをバイナリファイルのダウンロードであると見做して、当該ＳＳＬ／ＴＬＳトランザクションを無視（計測対象外）する。そして、以下に説明する方法で、通信データサイズの偏りが分析される。
本実施形態では、上記フローチャートで説明した通り、ネットワーク上で送受信されるリクエスト通信が集められ、この際、送受信された通信について、データサイズが記録される。具体的には、ＨＴＴＰ通信の場合、ある宛先Ｄｓｔに対するＨＴＴＰレスポンスについて、ＧＥＴメソッド、ＰＯＳＴ／ＰＵＴメソッド毎にヘッダー部を除いたデータ長が記録される。但し、レスポンスデータを検査することで、実行ファイルをＤＬしたと疑われる通信は除外される。また、ＳＳＬ／ＴＬＳ通信の場合、ある宛先Ｄｓｔに対するＳＳＬ／ＴＬＳトランザクションのＣｌｉｅｎｔからＳｅｒｖｅｒ向きのＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａ（ＣｔｏＳ）をリクエストデータとし、その直後のＳｅｒｖｅｒからＣｌｉｅｎｔ向きのＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａ（ＳｔｏＣ）をレスポンスデータとして、レスポンスデータそれぞれのＬｅｎｇｔｈフィールド値の合算値が記録される。なお、本実施形態では、途中にＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージ（ＣｔｏＳ）が割り込まない連続した一連のＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージ（ＳｔｏＣ）をレスポンスデータと見做し、そのＬｅｎｇｔｈフィールド値の合算値をレスポンスデータ長とするが、レスポンスデータ長が６５５３６（６４Ｋ）バイト以上である場合は、当該レスポンスをバイナリファイルのダウンロードであると見做して、当該ＳＳＬ／ＴＬＳトランザクションを無視（計測対象外）する。そして、以下に説明する方法で、通信データサイズの偏りが分析される。
【0088】
本実施形態では、分布算出部２４は、以下の手順で、記録されたレスポンスデータ長の集合の平均値を算出し、平均から大きく外れるデータ長を受信している数を求め、その数の大小で通信データサイズの偏りＢｏＲを算出する。本実施形態では、偏りＢｏＲは、０から１の範囲の値で出力され、１に近いほどデータ長に偏りがあると判定される。
（１）リクエストパケットＸｉ∈ＴＲ（ＴＲはリクエストの集合）に対応するレスポンスパケットのデータバイト長ＲＬ（Ｘｉ）（ｉ＝１～δ）をδ回（例えば、σ＋１回）計測して記録し、そのレスポンスデータ長の集合を集合ＲＬとする。
（２）レスポンスデータ長の集合ＲＬに対する上限閾値ＳＲＬを求める。
SRL= (Σi RL(Xi)/δ)*1.2 , RL(Xi)∈RL: SRL=平均データバイト長×1.2
（３）リクエストパケットＸｉに対応するレスポンスパケットのデータバイト長が上限閾値ＳＲＬを下回るリクエストパケットＸｉの集合ＴＲＳＲＬと、集合に含まれる要素数｜ＴＲＳＲＬ｜を求める。
TRSRL = { Xi∈TR | RL(Xi) ＜ SRL , RL(Xi)∈RL}
（４）レスポンスデータ長の偏りの度合いＢｏＲを以下の式で定義する。
BoR = |TRSRL| / δ , 0＜BoR≦1.0
（１）リクエストパケットＸｉ∈ＴＲ（ＴＲはリクエストの集合）に対応するレスポンスパケットのデータバイト長ＲＬ（Ｘｉ）（ｉ＝１～δ）をδ回（例えば、σ＋１回）計測して記録し、そのレスポンスデータ長の集合を集合ＲＬとする。
（２）レスポンスデータ長の集合ＲＬに対する上限閾値ＳＲＬを求める。
SRL= (Σi RL(Xi)/δ)*1.2 , RL(Xi)∈RL: SRL=平均データバイト長×1.2
（３）リクエストパケットＸｉに対応するレスポンスパケットのデータバイト長が上限閾値ＳＲＬを下回るリクエストパケットＸｉの集合ＴＲＳＲＬと、集合に含まれる要素数｜ＴＲＳＲＬ｜を求める。
TRSRL = { Xi∈TR | RL(Xi) ＜ SRL , RL(Xi)∈RL}
（４）レスポンスデータ長の偏りの度合いＢｏＲを以下の式で定義する。
BoR = |TRSRL| / δ , 0＜BoR≦1.0
【0089】
＜Ｃ＆Ｃ通信の検出＞
次に、Ｃ＆Ｃ通信の検出の流れを説明する。
次に、Ｃ＆Ｃ通信の検出の流れを説明する。
【0090】
＜＜ＨＴＴＰにおけるＣ＆Ｃ通信の検出＞＞
ＨＴＴＰを使用する個々のマルウェアのＣ＆Ｃ通信は、以下の特徴を有する。
（１）同一のＣ＆Ｃサーバ（宛先）に対して送受信されるＨＴＴＰリクエスト群のＵＲＩ形式やリクエストヘッダーの構成と形式は、メソッド毎に極めて類似している。即ち、正当なアプリケーションの通信に見られるような、複数の異なる形式のＵＲＩやリクエストヘッダーをもつＨＴＴＰリクエスト群が使用されることは、ほぼ無い。これは、マルウェアと攻撃者間の単純な情報交換だけが目的であることに起因している。
（２）同一のＣ＆Ｃサーバ（宛先）に対して送受信されるＨＴＴＰリクエストの代表的なリクエストヘッダーの値には、固定値が使用されることが多い。但し、Ｕｓｅｒ－Ａｇｅｎｔ，Ｃｏｏｋｉｅ，拡張／独自ヘッダーの値を使用して、Ｃ＆Ｃサーバに情報を伝達するマルウェアも存在する。
（３）同一のＣ＆Ｃサーバ（宛先）に対して送信されるＨＴＴＰリクエストの送信間隔（インターバル時間）は、メソッド毎に規則性（例えば、周期性）を有する。即ち、正当なアプリケーションの通信に比べ、Ｃ＆Ｃ通信の送信間隔は、規則性の度合いが高い。特に、この傾向は、Ｃ＆Ｃサーバへのチェックイン直後やビーコンパケット（Ｃ＆Ｃサーバへの指令問合せパケット）において顕著に見られる。
（４）Ｃ＆Ｃサーバから送信されるデータ（レスポンスデータ）は、バイナリ（実行ファイルのダウンロードフェーズ：マルウェアの更新、新規のマルウェア、各種ツール類）を除くと、マルウェアに対する構成定義情報（データ量：中～大）及び指令（データ量：小）である。このうち、構成定義情報が頻繁に送信されることは稀であり、大部分が指令で構成される。即ち、Ｃ＆Ｃサーバから送信されるデータ（レスポンスデータ）は、正当なアプリケーションに比べ、大部分または全てのレスポンスデータ長が特定のサイズに偏る度合いが高い。
ＨＴＴＰを使用する個々のマルウェアのＣ＆Ｃ通信は、以下の特徴を有する。
（１）同一のＣ＆Ｃサーバ（宛先）に対して送受信されるＨＴＴＰリクエスト群のＵＲＩ形式やリクエストヘッダーの構成と形式は、メソッド毎に極めて類似している。即ち、正当なアプリケーションの通信に見られるような、複数の異なる形式のＵＲＩやリクエストヘッダーをもつＨＴＴＰリクエスト群が使用されることは、ほぼ無い。これは、マルウェアと攻撃者間の単純な情報交換だけが目的であることに起因している。
（２）同一のＣ＆Ｃサーバ（宛先）に対して送受信されるＨＴＴＰリクエストの代表的なリクエストヘッダーの値には、固定値が使用されることが多い。但し、Ｕｓｅｒ－Ａｇｅｎｔ，Ｃｏｏｋｉｅ，拡張／独自ヘッダーの値を使用して、Ｃ＆Ｃサーバに情報を伝達するマルウェアも存在する。
（３）同一のＣ＆Ｃサーバ（宛先）に対して送信されるＨＴＴＰリクエストの送信間隔（インターバル時間）は、メソッド毎に規則性（例えば、周期性）を有する。即ち、正当なアプリケーションの通信に比べ、Ｃ＆Ｃ通信の送信間隔は、規則性の度合いが高い。特に、この傾向は、Ｃ＆Ｃサーバへのチェックイン直後やビーコンパケット（Ｃ＆Ｃサーバへの指令問合せパケット）において顕著に見られる。
（４）Ｃ＆Ｃサーバから送信されるデータ（レスポンスデータ）は、バイナリ（実行ファイルのダウンロードフェーズ：マルウェアの更新、新規のマルウェア、各種ツール類）を除くと、マルウェアに対する構成定義情報（データ量：中～大）及び指令（データ量：小）である。このうち、構成定義情報が頻繁に送信されることは稀であり、大部分が指令で構成される。即ち、Ｃ＆Ｃサーバから送信されるデータ（レスポンスデータ）は、正当なアプリケーションに比べ、大部分または全てのレスポンスデータ長が特定のサイズに偏る度合いが高い。
【0091】
本実施形態では、上記のマルウェアのＣ＆Ｃ通信の特徴を、以下のように定式化する。
TR(Dst): 宛先Dst宛てのHTTPリクエストの集合
TRG(Dst): 実行ファイルのダウンロードフェーズに該当しないGETリクエスト⊂TR(Dst) の集合
TRP(Dst): 実行ファイルのダウンロードフェーズに該当しないPOST/PUTリクエスト⊂TR(Dst)の集合
X: TRG(Dst)またはTRP(Dst)に属する基点とする（最初の）HTTPリクエスト
Y: TRG(Dst)またはTRP(Dst)に属するXに続く任意のHTTPリクエスト
RoIG(Dst): TRG(Dst)に属するHTTPリクエストの送信間隔の規則性の度合い
RoIP(Dst): TRP(Dst)に属するHTTPリクエストの送信間隔の規則性の度合い
BoRG(Dst): TRG(Dst)に属するHTTPリクエストのレスポンスデータ長の偏りの度合い
BoRP(Dst): TRP(Dst)に属するHTTPリクエストのレスポンスデータ長の偏りの度合い
TR(Dst): 宛先Dst宛てのHTTPリクエストの集合
TRG(Dst): 実行ファイルのダウンロードフェーズに該当しないGETリクエスト⊂TR(Dst) の集合
TRP(Dst): 実行ファイルのダウンロードフェーズに該当しないPOST/PUTリクエスト⊂TR(Dst)の集合
X: TRG(Dst)またはTRP(Dst)に属する基点とする（最初の）HTTPリクエスト
Y: TRG(Dst)またはTRP(Dst)に属するXに続く任意のHTTPリクエスト
RoIG(Dst): TRG(Dst)に属するHTTPリクエストの送信間隔の規則性の度合い
RoIP(Dst): TRP(Dst)に属するHTTPリクエストの送信間隔の規則性の度合い
BoRG(Dst): TRG(Dst)に属するHTTPリクエストのレスポンスデータ長の偏りの度合い
BoRP(Dst): TRP(Dst)に属するHTTPリクエストのレスポンスデータ長の偏りの度合い
【0092】
そして、本実施形態において、推定部２５は、以下の条件を全て満たすＤｓｔ宛ての通信を、Ｃ＆Ｃ通信であると推定する。
TRG(Dst) = {Y∈TRG(Dst) | SIMHTTP(X, Y)≧ ∂, X,∀Y∈TRG(Dst)} 且つ
TRP(Dst) = {Y∈TRP(Dst) | SIMHTTP(X, Y)≧ ∂, X,∀Y∈TRP(Dst)} 且つ
RoIG(Dst)≧ ρ または RoIP(Dst)≧ ρ 且つ
BoRG(Dst)≧ μ または BoRP(Dst)≧ μ
TRG(Dst) = {Y∈TRG(Dst) | SIMHTTP(X, Y)≧ ∂, X,∀Y∈TRG(Dst)} 且つ
TRP(Dst) = {Y∈TRP(Dst) | SIMHTTP(X, Y)≧ ∂, X,∀Y∈TRP(Dst)} 且つ
RoIG(Dst)≧ ρ または RoIP(Dst)≧ ρ 且つ
BoRG(Dst)≧ μ または BoRP(Dst)≧ μ
【0093】
＜＜ＳＳＬ／ＴＬＳにおけるＣ＆Ｃ通信の検出＞＞
ＳＳＬ／ＴＬＳプロトコルを使用する個々のマルウェアのＣ＆Ｃ通信は、以下の特徴を有する。
（１）同一のＣ＆Ｃサーバ（宛先）に対して送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔（インターバル時間）は、規則性（例えば、周期性）を有する。即ち、正当なアプリケーションのＳＳＬ／ＴＬＳ通信に比べ、ＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔の規則性の度合いが高い。特に、この傾向は、Ｃ＆Ｃサーバへのチェックイン直後やビーコンパケット（Ｃ＆Ｃサーバへの指令問合せパケット）において顕著に見られる。
（２）Ｃ＆Ｃサーバから送信されるＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージ（レスポンスデータ）は、バイナリ（マルウェアの更新、新規のマルウェア、各種ツール類）を除くと、マルウェアに対する構成定義情報（データ量：中～大）と指令（データ量：小）である。このうち、構成定義情報が頻繁に送信されることは稀であり、大部分が指令で構成される。即ち、Ｃ＆Ｃサーバから送信されるＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージは、正当なアプリケーションに比べ、大部分または全てのＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａのデータ長が特定のサイズに偏る度合いが高い。
ＳＳＬ／ＴＬＳプロトコルを使用する個々のマルウェアのＣ＆Ｃ通信は、以下の特徴を有する。
（１）同一のＣ＆Ｃサーバ（宛先）に対して送信されるＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔（インターバル時間）は、規則性（例えば、周期性）を有する。即ち、正当なアプリケーションのＳＳＬ／ＴＬＳ通信に比べ、ＣｌｉｅｎｔＨｅｌｌｏメッセージの送信間隔の規則性の度合いが高い。特に、この傾向は、Ｃ＆Ｃサーバへのチェックイン直後やビーコンパケット（Ｃ＆Ｃサーバへの指令問合せパケット）において顕著に見られる。
（２）Ｃ＆Ｃサーバから送信されるＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージ（レスポンスデータ）は、バイナリ（マルウェアの更新、新規のマルウェア、各種ツール類）を除くと、マルウェアに対する構成定義情報（データ量：中～大）と指令（データ量：小）である。このうち、構成定義情報が頻繁に送信されることは稀であり、大部分が指令で構成される。即ち、Ｃ＆Ｃサーバから送信されるＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａメッセージは、正当なアプリケーションに比べ、大部分または全てのＡｐｐｌｉｃａｔｉｏｎ Ｄａｔａのデータ長が特定のサイズに偏る度合いが高い。
【0094】
本実施形態では、上記のマルウェアのＣ＆Ｃ通信の特徴を定式化する。
TRS(Dst): 宛先Dst宛てのSSL/TLSトランザクション（ClientHelloメッセージからEncrypted Alertメッセージまでの一連のSSL/TLSメッセージ群）の集合
BR(CH(Dst)): ブラウザによるSSL/TLSトランザクションの十分条件
RoIS(Dst): TRS(Dst)に属するClientHelloメッセージの送信間隔の規則性の度合い
BoRS(Dst): TRS(Dst)に属するApplication Dataメッセージ(StoC)のデータ長の偏りの度合い
TRS(Dst): 宛先Dst宛てのSSL/TLSトランザクション（ClientHelloメッセージからEncrypted Alertメッセージまでの一連のSSL/TLSメッセージ群）の集合
BR(CH(Dst)): ブラウザによるSSL/TLSトランザクションの十分条件
RoIS(Dst): TRS(Dst)に属するClientHelloメッセージの送信間隔の規則性の度合い
BoRS(Dst): TRS(Dst)に属するApplication Dataメッセージ(StoC)のデータ長の偏りの度合い
【0095】
そして、本実施形態において、推定部２５は、以下の条件を全て満たすＤｓｔ宛ての通信を、Ｃ＆Ｃ通信であると推定する。なお、本実施形態では、業務通信の大半を占めるブラウザ通信を対象から除外することで、誤検出及び処理負荷を低減することとしている。
￢BR(CH(Dst))（ブラウザによるＳＳＬ／ＴＬＳ通信ではない） 且つ
RoIS(Dst)≧ ρ 且つ
BoRS(Dst)≧ μ
￢BR(CH(Dst))（ブラウザによるＳＳＬ／ＴＬＳ通信ではない） 且つ
RoIS(Dst)≧ ρ 且つ
BoRS(Dst)≧ μ
【0096】
＜マルウェア・ファミリーの推定＞
次に、マルウェア・ファミリーの推定の流れを説明する。
次に、マルウェア・ファミリーの推定の流れを説明する。
【0097】
＜＜ＨＴＴＰにおけるマルウェア・ファミリーの推定＞＞
本実施形態において、推定部２５は、学習データベースＭａｌＤＢに登録されている既知マルウェアのＨＴＴＰトラフィックを使用して、既知または亜種（未知）のマルウェアを検出し、名前を推定する。
本実施形態において、推定部２５は、学習データベースＭａｌＤＢに登録されている既知マルウェアのＨＴＴＰトラフィックを使用して、既知または亜種（未知）のマルウェアを検出し、名前を推定する。
【0098】
類似度算出部２３は、名前を推定したいマルウェアβが送受信するＨＴＴＰトラフィックＹ（β）に対して、ＭａｌＤＢに登録されているマルウェア（例えば、全てのマルウェア）のトラフィック（例えば、全てのトラフィック）との類似度ＳＩＭＨＴＴＰ（Ｙ（β），Ｘ（α））を計算し、類似度が最大となるＨＴＴＰトラフィックが属するマルウェアαを求める。そして、推定部２５は、最大の類似度ＳＩＭＨＴＴＰを、同種であると判定するための閾値Ａ及び亜種であると判定するための閾値Ｂ（ここで、閾値Ａ＞閾値Ｂ）と比較することで、対象の通信に係るマルウェアが、最大の類似度ＳＩＭＨＴＴＰを有する既知のマルウェアの同種であるか、亜種であるか、又は別種であるかを推定する。
【0099】
なお、上記の判定において、ＳＩＭＨＴＴＰ（Ｙ（β），Ｘ（α））が同じ値になる複数のマルウェアαｉ（ｉ：マルウェアＩＤ）が存在した場合は、以下に示す個々の類似度の合算値を順番に評価し、より値が大きいＨＴＴＰトラフィックが属するマルウェアαｉを選択する。
Sr(Y(β),X(αi)) + Sp(Y(β),X(αi))
Sr(Y(β),X(αi)) + Sp(Y(β),X(αi)) + So(Y(β),X(αi))
Sr(Y(β),X(αi)) + Sp(Y(β),X(αi)) + So(Y(β),X(αi)) + Sn(Y(β),X(αi))
Sr(Y(β),X(αi)) + Sp(Y(β),X(αi))
Sr(Y(β),X(αi)) + Sp(Y(β),X(αi)) + So(Y(β),X(αi))
Sr(Y(β),X(αi)) + Sp(Y(β),X(αi)) + So(Y(β),X(αi)) + Sn(Y(β),X(αi))
【0100】
＜＜ＳＳＬ／ＴＬＳにおけるマルウェア・ファミリーの推定＞＞
本実施形態において、推定部２５は、学習データベースＭａｌＤＢに登録されている既知マルウェアのＳＳＬ／ＴＬＳトラフィックを使用して、既知または亜種（未知）のマルウェアを検出し、名前を推定する。
本実施形態において、推定部２５は、学習データベースＭａｌＤＢに登録されている既知マルウェアのＳＳＬ／ＴＬＳトラフィックを使用して、既知または亜種（未知）のマルウェアを検出し、名前を推定する。
【0101】
類似度算出部２３は、名前を推定したいマルウェアβが送受信するＳＳＬ／ＴＬＳトラフィックＴ（β）に対して、ＭａｌＤＢに登録されているマルウェア（例えば、全てのマルウェア）のトラフィック（例えば、全てのトラフィック）との類似度ＳＩＭＴＬＳ（Ｔ（β），Ｓ（α））を計算し、類似度が最大となるＳＳＬ／ＴＬＳトラフィックが属するマルウェアαを求める。そして、推定部２５は、最大の類似度ＳＩＭＴＬＳを、同種であると判定するための閾値Ａ及び亜種であると判定するための閾値Ｂ（ここで、閾値Ａ＞閾値Ｂ）と比較することで、対象の通信に係るマルウェアが、最大の類似度ＳＩＭＴＬＳを有する既知のマルウェアの同種であるか、亜種であるか、又は別種であるかを推定する。
【0102】
なお、上記の判定において、ＳＩＭＴＬＳ（Ｔ（β），Ｓ（α））が同じ値になる複数のマルウェアαi（ｉ：マルウェアＩＤ）が存在した場合、推定部２５は、上述した「パターンの平均リクエストサイズＡｏＳＰ（Ａｖｅｒａｇｅ ｏｆ ｒｅｑｕｅｓｔ Ｓｉｚｅ Ｐａｔｔｅｒｎｓ）」により近い値を持つＳＳＬ／ＴＬＳトラフィックが属するマルウェアαiを選択する。
【0103】
＜感染範囲の推定＞
次に、マルウェアの感染範囲の推定の流れを説明する。監視対象のホストＨが何らかのマルウェアに感染している場合、複数の種類のマルウェアに同時に感染している場合が考えられる。例えば、１ｓｔステージ、２ｎｄステージなど段階を追ってマルウェアが送り込まれてくる場合が考えられる。一般的に、マルウェア毎にＣ＆Ｃサーバとの通信に使用されるトラフィック（Ｃ＆Ｃトラフィック）の特徴が異なるため、ホストＨで検出しているＣ＆Ｃトラフィックを類似度に基づいて分類することで、マルウェアαとマルウェアαのＣ＆Ｃトラフィック群との対応関係、及びマルウェアαのＣ＆Ｃトラフィック群とマルウェアαのＣ＆Ｃサーバアドレス群との対応関係が得られ、感染しているマルウェアの種類単位で、感染範囲を推定することができる。
次に、マルウェアの感染範囲の推定の流れを説明する。監視対象のホストＨが何らかのマルウェアに感染している場合、複数の種類のマルウェアに同時に感染している場合が考えられる。例えば、１ｓｔステージ、２ｎｄステージなど段階を追ってマルウェアが送り込まれてくる場合が考えられる。一般的に、マルウェア毎にＣ＆Ｃサーバとの通信に使用されるトラフィック（Ｃ＆Ｃトラフィック）の特徴が異なるため、ホストＨで検出しているＣ＆Ｃトラフィックを類似度に基づいて分類することで、マルウェアαとマルウェアαのＣ＆Ｃトラフィック群との対応関係、及びマルウェアαのＣ＆Ｃトラフィック群とマルウェアαのＣ＆Ｃサーバアドレス群との対応関係が得られ、感染しているマルウェアの種類単位で、感染範囲を推定することができる。
【0104】
本実施形態において、情報処理装置は、以下の手順で、ホストＨについて検出されているＣ＆Ｃサーバのアドレス群ＣＣ（Ｈ）を、トラフィックの類似度に基づいてｎ個の互いに素なクラスＣＣ（Ｈ）ｉ（ｉ＝１．．．ｎ）に分類する。
（１）分類の基点とするＣ＆ＣサーバアドレスＡ１∈ＣＣ（Ｈ）を任意に選択する。
（２）類似度評価関数（ＳＩＭＨＴＴＰまたはＳＩＭＴＬＳ）を用いて、ｎ個の互いに素なクラスに分類する。ここで分類されたＣＣ（Ｈ）ｉ（ｉ＝１．．．ｎ）には、以下の関係が成立する。ここで、ＴＲ（Ｈ）は、ホストＨについて検出されたＣ＆Ｃトラフィック群を表す。
CC(H)=CC(H)1∪CC(H)2∪・・・∪CC(H)n 但し、i≠j ならば CC(H)i∩CC(H)j={}
TR(H)=TR(CC(H)1:H)∪TR(CC(H)2:H)∪・・・∪TR(CC(H)n:H)
CC(H)k ⇔ TR(CC(H)k:H) ⇔ マルウェアαk ; 1対1に対応する。
（１）分類の基点とするＣ＆ＣサーバアドレスＡ１∈ＣＣ（Ｈ）を任意に選択する。
（２）類似度評価関数（ＳＩＭＨＴＴＰまたはＳＩＭＴＬＳ）を用いて、ｎ個の互いに素なクラスに分類する。ここで分類されたＣＣ（Ｈ）ｉ（ｉ＝１．．．ｎ）には、以下の関係が成立する。ここで、ＴＲ（Ｈ）は、ホストＨについて検出されたＣ＆Ｃトラフィック群を表す。
CC(H)=CC(H)1∪CC(H)2∪・・・∪CC(H)n 但し、i≠j ならば CC(H)i∩CC(H)j={}
TR(H)=TR(CC(H)1:H)∪TR(CC(H)2:H)∪・・・∪TR(CC(H)n:H)
CC(H)k ⇔ TR(CC(H)k:H) ⇔ マルウェアαk ; 1対1に対応する。
【0105】
＜＜ＨＴＴＰにおける感染範囲の推定＞＞
続く処理は、通信がＨＴＴＰである場合とＳＳＬ／ＴＬＳである場合とで異なる。通信がＨＴＴＰである場合、推定部２５は、Ｃ＆Ｃサーバとの通信にＨＴＴＰを使用するマルウェアに対して、感染ホストＨと同じ種類のマルウェアに感染しているホスト群Ｈｍ（即ち、感染範囲）を、以下の手順で推定する。
続く処理は、通信がＨＴＴＰである場合とＳＳＬ／ＴＬＳである場合とで異なる。通信がＨＴＴＰである場合、推定部２５は、Ｃ＆Ｃサーバとの通信にＨＴＴＰを使用するマルウェアに対して、感染ホストＨと同じ種類のマルウェアに感染しているホスト群Ｈｍ（即ち、感染範囲）を、以下の手順で推定する。
【0106】
（１）感染範囲を推定するための起点とする対象ホストＨを選択する。
（２）ホストＨを除く、他のＣ＆Ｃ通信と認定したＨＴＴＰリクエストパケット、及びＣ＆Ｃサーバアドレスが記録されている監視対象ホストから、対象ＨＴＴＰリクエストパケットとの類似性が所定以上であるか又はＣ＆Ｃサーバアドレスが同一であるホスト群Ｉｎｆ（Ｈ）を抽出する。
（３）（２）で抽出されたホスト群Ｉｎｆ（Ｈ）を、ホストＨが感染しているマルウェアと同種のマルウェアに感染しているホスト群Ｈｍ、即ち、感染範囲と推定する。更に、基点とする対象ホストＨが感染している個々のマルウェアαｋの感染範囲を推定するには、マルウェアαｋに対応するＣ＆Ｃサーバアドレス群、及びＣ＆Ｃトラフィック群の範囲内でホスト群Ｉｎｆ（Ｈ）（＝Ｉｎｆ（Ｈ｜αｋ）を求めればよい。
（２）ホストＨを除く、他のＣ＆Ｃ通信と認定したＨＴＴＰリクエストパケット、及びＣ＆Ｃサーバアドレスが記録されている監視対象ホストから、対象ＨＴＴＰリクエストパケットとの類似性が所定以上であるか又はＣ＆Ｃサーバアドレスが同一であるホスト群Ｉｎｆ（Ｈ）を抽出する。
（３）（２）で抽出されたホスト群Ｉｎｆ（Ｈ）を、ホストＨが感染しているマルウェアと同種のマルウェアに感染しているホスト群Ｈｍ、即ち、感染範囲と推定する。更に、基点とする対象ホストＨが感染している個々のマルウェアαｋの感染範囲を推定するには、マルウェアαｋに対応するＣ＆Ｃサーバアドレス群、及びＣ＆Ｃトラフィック群の範囲内でホスト群Ｉｎｆ（Ｈ）（＝Ｉｎｆ（Ｈ｜αｋ）を求めればよい。
【0107】
＜＜ＳＳＬ／ＴＬＳにおける感染範囲の推定＞＞
通信がＳＳＬ／ＴＬＳである場合、推定部２５は、Ｃ＆Ｃサーバとの通信にＳＳＬ／ＴＬＳプロトコルを使用するマルウェアに対して、感染ホストＨと同じ種類のマルウェアに感染しているホスト群Ｈｍ（即ち、感染範囲）を、以下の手順で推定する。なお、ＳＳＬ／ＴＬＳプロトコルベースのＣ＆Ｃ通信として検出したＣ＆Ｃサーバ候補に対して、類似度評価関数ＳＩＭＴＬＳ（Ｓ，Ｔ）が要求する情報（特徴量）が収集されているものとする。
通信がＳＳＬ／ＴＬＳである場合、推定部２５は、Ｃ＆Ｃサーバとの通信にＳＳＬ／ＴＬＳプロトコルを使用するマルウェアに対して、感染ホストＨと同じ種類のマルウェアに感染しているホスト群Ｈｍ（即ち、感染範囲）を、以下の手順で推定する。なお、ＳＳＬ／ＴＬＳプロトコルベースのＣ＆Ｃ通信として検出したＣ＆Ｃサーバ候補に対して、類似度評価関数ＳＩＭＴＬＳ（Ｓ，Ｔ）が要求する情報（特徴量）が収集されているものとする。
【0108】
（１）感染範囲を推定するための起点とする対象ホストＨを選択する。
（２）ホストＨを除く、Ｃ＆Ｃ通信と認定したＳＳＬ／ＴＬＳトランザクション、及びＣ＆Ｃサーバアドレスが記録されている監視対象ホストから、対象ＳＳＬ／ＴＬＳトランザクションとの類似性が所定以上であるか又はＣ＆Ｃサーバアドレスが同一であるホスト群Ｉｎｆ（Ｈ）を抽出する。
（３）（２）で抽出されたホスト群Ｉｎｆ（Ｈ）を、ホストＨが感染しているマルウェアと同種のマルウェアに感染しているホスト群Ｈｍ、即ち、感染範囲と推定する。更に、基点とする対象ホストＨが感染している個々のマルウェアαｋの感染範囲を推定するには、マルウェアαｋに対応するＣ＆Ｃサーバアドレス群、及びＣ＆Ｃトラフィック群の範囲内でホスト群Ｉｎｆ（Ｈ）（＝Ｉｎｆ（Ｈ｜αｋ）を求めればよい。
（２）ホストＨを除く、Ｃ＆Ｃ通信と認定したＳＳＬ／ＴＬＳトランザクション、及びＣ＆Ｃサーバアドレスが記録されている監視対象ホストから、対象ＳＳＬ／ＴＬＳトランザクションとの類似性が所定以上であるか又はＣ＆Ｃサーバアドレスが同一であるホスト群Ｉｎｆ（Ｈ）を抽出する。
（３）（２）で抽出されたホスト群Ｉｎｆ（Ｈ）を、ホストＨが感染しているマルウェアと同種のマルウェアに感染しているホスト群Ｈｍ、即ち、感染範囲と推定する。更に、基点とする対象ホストＨが感染している個々のマルウェアαｋの感染範囲を推定するには、マルウェアαｋに対応するＣ＆Ｃサーバアドレス群、及びＣ＆Ｃトラフィック群の範囲内でホスト群Ｉｎｆ（Ｈ）（＝Ｉｎｆ（Ｈ｜αｋ）を求めればよい。
【0109】
＜バリエーション＞
上記説明した実施形態では、ネットワーク監視装置２０が、スイッチまたはルータのモニタリングポート（ミラーポート）に接続されることでノード９０によって送受信されるパケットやフレーム等を取得する例について説明した（図１を参照）。但し、上記実施形態に示したネットワーク構成は、本開示を実施するための一例であり、実施にあたってはその他のネットワーク構成が採用されてもよい。
上記説明した実施形態では、ネットワーク監視装置２０が、スイッチまたはルータのモニタリングポート（ミラーポート）に接続されることでノード９０によって送受信されるパケットやフレーム等を取得する例について説明した（図１を参照）。但し、上記実施形態に示したネットワーク構成は、本開示を実施するための一例であり、実施にあたってはその他のネットワーク構成が採用されてもよい。
【0110】
例えば、ネットワーク監視装置２０は、モニタリングポート（ミラーポート）に接続されず、単にネットワークセグメント２に接続されている場合であっても、ネットワークセグメント２を流れるフレームを、自身のＭＡＣアドレス宛でないものも含めて取得することで、ノード９０によって送受信されるパケットやフレーム等を取得することが出来る。この場合も、ネットワーク監視装置２０は、パッシブモードで動作してよい。また、例えば、ネットワーク監視装置２０は、ネットワークセグメント２のスイッチまたはルータと、その上位にある他のスイッチまたはルータと、の間に接続されることで、通過するパケットやフレーム等を取得してもよい（図９を参照）。この場合、ネットワーク監視装置２０は、取得したパケットのうち、遮断しなくてもよいパケットについては転送するインラインモードで動作する。また、ネットワーク監視装置２０は、ルータまたはスイッチに内包されてもよい。
【0111】
なお、本実施形態では、ネットワークを流れるパケットを取得して、上記した各種の検知エンジンによりリアルタイムで検知を行う実施形態について説明したが、本開示の適用範囲は、リアルタイム検知に限定されない。例えば、ネットワークを流れる通信に係るデータを蓄積しておいて、蓄積されたデータに対して上記した各種の検知エンジンによる処理を行うこととしてもよい。
【0112】
＜効果＞
上記説明した実施形態によれば、同一の通信先に係る通信の属性情報の分布を算出し、分布が所定の基準を満たす場合に、検出された通信が所定の種類のソフトウェア（本実施形態では、マルウェア）による通信で有ると推定することで、マルウェア等の所定の種類のソフトウェアによる、正常な通信に偽装した通信を検出することが可能となる。
上記説明した実施形態によれば、同一の通信先に係る通信の属性情報の分布を算出し、分布が所定の基準を満たす場合に、検出された通信が所定の種類のソフトウェア（本実施形態では、マルウェア）による通信で有ると推定することで、マルウェア等の所定の種類のソフトウェアによる、正常な通信に偽装した通信を検出することが可能となる。
【0113】
例えば、上記説明した実施形態によれば、ある通信先に対する通信の構造的な類似度を検査し、類似した通信が複数回連続で行われて規定回数を超えた際に通信タイミングの規則性、通信データサイズの偏り度合いを算出し、マルウェアのＣ＆Ｃ通信を検出することが可能となる。これは、マルウェアが、ユーザーが操作するブラウザ通信とは異なり、ある宛先に対して同じデータ構造で周期的に通信を行なう傾向があり、また、マルウェアが攻撃者からの命令を待ち受けている間、サーバ側からの応答として返されるデータサイズは、ほぼ同じサイズになる傾向があるためである。
【0114】
更に、上記説明した実施形態によれば、ある感染端末でマルウェア感染が発覚した際に、そのマルウェアのＣ＆Ｃ通信と類似した通信を行っている組織内の感染端末を通信の構造的な類似度を特徴量として推定することが可能となる。これは、マルウェアが、同種マルウェアであれば、構造的に類似した通信を行なう特徴があるためである。
【0115】
更に、上記説明した実施形態によれば、ある感染端末でマルウェア感染が発覚した際に、そのマルウェアのＣ＆Ｃ通信と類似した通信を行うマルウェア・ファミリーをデータベースより通信の構造的な類似度を特徴量として検索することが可能となる。これは、マルウェアが、同種マルウェアであれば、構造的に類似した通信を行なう特徴があるためである。
【符号の説明】
【0116】
２０ ネットワーク監視装置
５０ 管理サーバー
５０ 管理サーバー
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】