(57)【要約】      （修正有）【課題】パケットに含まれるデータの一部が意図的変更された場合であっても、スパムメールやマルウェアを検知できる悪意メール検出技術を提供する。【解決手段】比較対象として用いられるメールに含まれる文字列パターンの特徴量を記憶する記憶手段１７０と、受信メールのうち予め定義された演算対象範囲である文字列パターンの特徴量を算出する演算手段１２０と、前記演算手段により算出された前記受信メールの文字列パターンの特徴量と、前記記憶されている文字列パターンの特徴量との類否により、前記メールが悪意メールか否かを判断する判断手段１３０，１４０とを有する悪意メール検出装置５０。【選択図】図３
2008192122.tif 000002
【特許請求の範囲】
【請求項１】
比較対象として用いられるメールに含まれる文字列パターンの特徴量を記憶する記憶手段と、
受信メールのうち予め定義された演算対象範囲の文字列パターンの特徴量を算出する演算手段と、
前記演算手段により算出された前記受信メールの文字列パターンの特徴量と、前記記憶されている文字列パターンの特徴量との類否により、前記メールが悪意メールか否かを判断する判断手段と
を有することを特徴とする悪意メール検出装置。
【請求項２】
前記特徴量は、文字列パターンを構成する1文字以上の文字列の出現頻度の集合であることを特徴とする請求項１に記載の悪意メール検出装置。
【請求項３】
前記判断手段は、前記比較対象として用いられるメールが悪意メールと認定されたメールであり文字列パターンを構成する文字列が1文字である場合に、前記演算手段により算出された前記受信メールの文字列パターンを構成する全文字に対する各文字の出現頻度と、前記記憶されている文字列パターンを構成する全文字に対する各文字の出現頻度との差分を算出し、この文字毎に算出された差分値の平均値が所定の閾値よりも小さい場合に、前記受信メールが悪意メールと判断するように構成されていることを特徴とする請求項２に記載の悪意メール検出装置。
【請求項４】
前記判断手段は、前記比較対象として用いられるメールが悪意メールでないと認定されたメールであり文字列パターンを構成する文字列が1文字である場合に、前記演算手段により算出された前記受信メールの文字列パターンを構成する全文字に対する各文字の出現頻度と、前記記憶されている文字列パターンを構成する全文字に対する各文字の出現頻度との差分を算出し、この文字毎に算出された差分値の平均値が所定の閾値よりも大きい場合に、前記受信メールが悪意メールと判断するように構成されていることを特徴とする請求項２に記載の悪意メール検出装置。
【請求項５】
前記演算手段の算出対象となる文字列パターンは受信メールに含まれるＵＲＬであり、前記記憶されている文字列パターンは、スパムメールから抽出されたＵＲＬであることを特徴とする請求項１から請求項４のいずれかに記載の悪意メール検出装置。
【請求項６】
前記演算手段の算出対象となる文字列パターンは、受信メールの添付ファイルにおける予め定義された演算対象範囲内の文字列パターンであり、前記記憶されている文字列パターンは、マルウェアから抽出された文字列パターンであることを特徴とする請求項１から請求項４のいずれかに記載の悪意メール検出装置。
【請求項７】
前記演算手段の算出対象となる文字列パターンは、受信メールの予め定義された演算対象範囲内の文字列パターンであり、前記記憶されている文字列パターンは、スパムメールから抽出された文字列パターンであることを特徴とする請求項１から請求項４のいずれかに記載の悪意メール検出装置。
【請求項８】
前記悪意メール検出装置は、前記判断手段によって受信メールが悪意メールであると判断された場合に、この受信メールを廃棄、遮断、または記録する処理手段を有することを特徴とする請求項１から請求項７に記載の悪意メール検出装置。
【請求項９】
前記悪意メール検出装置は、
所定の規則に従って、受信したメールから、少なくとも一つ以上のストリームを構築する構築手段と、
前記構築手段によって構築されたストリームをストリーム毎に管理し、前記演算手段による特徴量の算出の終了を受けて、前記ストリームの管理のためのメモリ領域の解放をストリーム単位で行うメモリ解放手段と
を有することを特徴とする請求項１から請求項８のいずれかに記載の悪意メール検出装置。
【請求項１０】
前記演算手段は、前記構築手段によって構築されたストリーム毎に特徴量を算出するように構成されていることを特徴とする請求項９に記載の悪意メール検出装置。
【請求項１１】
前記メモリ領域に格納される情報は、受信メールのパケットの接続情報、受信メールのパケットのプロトコルの状態遷移、及び、前記処理単位に相当するストリームを特定する為の識別情報の少なくともいずれか一つを含む情報であることを特徴とする請求項９または請求項１０のいずれかに記載の悪意メール検出装置。
【請求項１２】
受信メールのうち予め定義された演算対象範囲の文字列パターンの特徴量を算出する演算ステップと、
前記演算ステップにより算出された前記受信メールの文字列パターンの特徴量と、記憶されている文字列パターンの特徴量との類否により、前記メールが悪意メールか否かを判断する判断ステップと
を有することを特徴とする悪意メール検出方法。
【請求項１３】
前記特徴量は、文字列パターンを構成する1文字以上の文字列の出現頻度の集合であることを特徴とする請求項１２に記載の悪意メール検出方法。
【請求項１４】
前記判断ステップは、比較対象として用いられるメールが悪意メールと認定されたメールであり文字列パターンを構成する文字列が1文字である場合に、前記演算ステップにより算出された前記受信メールの文字列パターンを構成する全文字に対する各文字の出現頻度と、前記記憶されている文字列パターンを構成する全文字に対する各文字の出現頻度との差分を算出し、この文字毎に算出された差分値の平均値が所定の閾値よりも小さい場合に、前記受信メールが悪意メールと判断することを特徴とする請求項１３に記載の悪意メール検出方法。
【請求項１５】
前記判断ステップは、比較対象として用いられるメールが悪意メールでないと認定されたメールであり文字列パターンを構成する文字列が1文字である場合に、前記演算ステップにより算出された前記受信メールの文字列パターンを構成する全文字に対する各文字の出現頻度と、前記記憶されている文字列パターンを構成する全文字に対する各文字の出現頻度との差分を算出し、この文字毎に算出された差分値の平均値が所定の閾値よりも大きい場合に、前記受信メールが悪意メールと判断することを特徴とする請求項１３に記載の悪意メール検出方法。
【請求項１６】
前記演算ステップにおける算出対象となる文字列パターンは受信メールに含まれるＵＲＬであり、前記記憶されている文字列パターンは、スパムメールから抽出されたＵＲＬであることを特徴とする請求項１２から請求項１５のいずれかに記載の悪意メール検出方法。
【請求項１７】
前記演算ステップにおける算出対象となる文字列パターンは、受信メールの添付ファイルにおける予め定義された演算対象範囲内の文字列パターンであり、前記記憶されている文字列パターンは、マルウェアから抽出された文字列パターンであることを特徴とする請求項１２から請求項１５のいずれかに記載の悪意メール検出方法。
【請求項１８】
前記演算ステップにおける算出対象となる文字列パターンは、受信メールの予め定義された演算対象範囲内の文字列パターンであり、前記記憶されている文字列パターンは、スパムメールから抽出された文字列パターンであることを特徴とする請求項１２から請求項１５のいずれかに記載の悪意メール検出方法。
【請求項１９】
前記悪意メール検出方法は、前記判断ステップによって受信メールが悪意メールであると判断された場合に、この受信メールを廃棄、遮断、または記録する処理ステップを有することを特徴とする請求項１２から請求項１８に記載の悪意メール検出方法。
【請求項２０】
所定の規則に従って、受信したメールから、少なくとも一つ以上のストリームを構築し、この構築したストリームをストリーム毎に管理し、前記演算ステップによる特徴量の算出の終了を受けて、前記ストリームの管理のためのメモリ領域の解放をストリーム単位で行うステップを有することを特徴とする請求項１２から請求項１９のいずれかに記載の悪意メール検出方法。
【請求項２１】
前記演算ステップは、前記構築されたストリーム毎に特徴量を算出することを特徴とする請求項２０に記載の悪意メール検出方法。
【請求項２２】
前記メモリ領域に格納される情報は、受信メールのパケットの接続情報、受信メールのパケットのプロトコルの状態遷移、及び、前記処理単位に相当するストリームを特定する為の識別情報の少なくともいずれか一つを含む情報であることを特徴とする請求項２０又は請求項２１のいずれかに記載の悪意メール検出方法。
【請求項２３】
情報処理装置のプログラムであって、前記プログラムは情報処理装置に、
受信メールのうち予め定義された演算対象範囲の文字列パターンの特徴量を算出する演算処理と、
前記演算ステップにより算出された前記受信メールの文字列パターンの特徴量と、記憶されている文字列パターンの特徴量との類否により、前記メールが悪意メールか否かを判断する判断処理と
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、悪意のこめられたメールを検出する悪意メール検出装置に関し、特に、パケットに含まれるデータの一部が意図的変更された悪意メールであっても検出できる悪意メール検出技術を提供することに関する。
【背景技術】
【０００２】
インターネットの普及に伴い、スパムメールによる被害が深刻化している。スパムメールとは、メール受信者の都合を考慮せず一方的に送られてくる、所謂、迷惑メールである。スパムメールを受信すると、受信したコンピュータのハードディスクやメモリ等のリソースが徒に消費され、コンピュータに接続されているネットワークにも負荷がかかる。スパムメールは、今やネットワークにおける脅威の一つとなっており、種々のスパムメール対策として種々の方法が検討されてきている。
【０００３】
従来から行われている対策として、あらかじめ登録したパターンと受信したメールとを照合するパターンマッチングによる手法がある。この手法は、受信したメールにＵＲＬ等のある特定の文字列が含まれていた場合に、スパムメールであると判断する手法（ＵＲＬフィルタリング）である。スパムメールには、スパムメールの受信者に参照させようとする誘導先サイトのＵＲＬが示されていることが多いため、この特徴を利用したものである。具体的には、メールに含まれているＵＲＬと予めデータベースに登録されているＵＲＬとを比較し、完全に一致した場合に、該当メールをスパムメールと見なす手法である。
【０００４】
しかしながら、こうした従来の手法は、管理者側で照合用のデータベースを管理する等、都度メンテナンスが必要であり運用コストがかかるという問題点があった。スパムメールの検出率も、低かった。
【０００５】
こうした背景から、スパムメールの検出率を高め、管理者負担を軽減するべく、いくつかの技術が提案されてきている。
【０００６】
例えば、メール流量数が所定の閾値を超えた場合、または、判定ワードの一部が受信メールの本文中に含まれている場合に迷惑メールであると判定し、迷惑メールと判定された電子メール中のＵＲＬを判定ワード候補として登録する技術が提案されてきている（特許文献１）。特許文献１の発明によれば、ＵＲＬが完全一致した場合に限らず、一部の判定ワードが一致した場合でも迷惑メールであると判定できるため検出精度が向上する。また、ＵＲＬ登録手段が、迷惑メールからＵＲＬを抽出して直接ブラックリストを生成するので、管理者負担が軽減される。
【０００７】
また、スパム検出を促進させる目的で追加の特徴（例えば、Ｎグラムに基づいてキャラクタＮグラムについての特徴）を作成し、キャラクタシーケンスのエントロピーについての特徴を作成し、機械学習システムを使用してフィルタをトレーニングすることで、スパムを検出し防止するスパム検出技術が提案されてきている（特許文献２）。特許文献２の発明においては、従来技術のスパムフィルタが一般に使用している特徴を超える追加の特徴を含めることによって、スパムメールの検出精度を向上させている。
【特許文献１】特開２００５−２０８７８０号公報
【特許文献２】特開２００５−０１８７４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、こうした技術が提案されてきているものの、確実にスパムメールを検出することは難しかった。例えば、特許文献１の発明では、受信したメールに判定ワードの一部が含まれていた場合であっても検出できるが、ＵＲＬの一部が意図的に変更されてしまうと検出ができなくなるという問題点があった。特許文献２の発明では、機械学習システムを使用してフィルタをトレーニングすることでスパムメールの検出精度を向上させてはいるものの、パケットに含まれるデータの一部を意図的に変更されたスパムメールについては、検知することができないという問題点があった。
【０００９】
すなわち、特許文献１及び特許文献２の発明を含む従来の検出手法では、新規のスパムメールの出現頻度のサイクルよりも、スパムメールに含まれるＵＲＬを登録する作業にかかる時間が短いことが前提とされていた。そのため、メールの本文をほとんど変えずに既知のＵＲＬを意図的に一部変更しているスパムメールを受信した場合には、データベースへのＵＲＬ登録／フィルタの更新が追いつかず、スパムメールがＵＲＬフィルタリングをすり抜けてしまうという問題点があった。
【００１０】
パケットに含まれるデータの一部を意図的に変更されて検出が回避されてしまうという問題は、スパムメールに限られた事ではなかった。例えば、特許文献１及び特許文献２の発明を含む従来の検出手法では、マルウェア（ｍａｌｉｃｉｏｕｓ  ｓｏｆｔｗａｒｅ：悪意のこもったソフトウェア）の検出も困難であった。これには複数の理由があった。
【００１１】
第一の理由として、マルウェアは、次々とその亜種が登場するため、パターンファイルの作成が追いつかないということがある。
【００１２】
第二の理由として、亜種の種類は多いが各亜種の絶対数が少なく、検体の入手が困難なこと、それ故に、パターンファイルの作成も困難であるということがある。
【００１３】
第三の理由として、マルウェアは、感染過程で自分自身を複製して感染させる対象となるコンピュータへ送り込むが、このときマルウェアは、検知されるのを回避するため自データの一部を変更して複製を行う為、特許文献１及び特許文献２の発明を含む従来の検出手法では検知し難いことがあげられる。
【００１４】
更に、前述したように、スパムメールを受信したコンピュータでは、ハードディスクやメモリ等のリソースが徒に消費され、コンピュータに接続されているネットワークにも負荷がかかる。例えば、トラフィック量の多い環境下でスパムメールを検知する場合、受信メールによるセッションの管理やメールの本文を検査するための処理に多くのメモリ容量を必要とし、処理コストがかかる。これを解決するべくハードウェアスペックを上げていくと、今度は、装置コストが高くなるという問題が生じる。
【００１５】
従って、本発明が解決しようとする課題は、パケットに含まれるデータの一部が意図的変更された場合であっても、スパムメールやマルウェアを検知できる悪意メール検出技術を提供することである。
【００１６】
更に、本発明が解決しようとする課題は、悪意メールの検出処理の効率化を図り、処理コストを抑えた悪意メール検出技術を提供することでもある。
【課題を解決するための手段】
【００１７】
上記課題を解決するための第１の発明は、比較対象として用いられるメールに含まれる文字列パターンの特徴量を記憶する記憶手段と、受信メールのうち予め定義された演算対象範囲の文字列パターンの特徴量を算出する演算手段と、前記演算手段により算出された前記受信メールの文字列パターンの特徴量と、前記記憶されている文字列パターンの特徴量との類否により、前記メールが悪意メールか否かを判断する判断手段とを有することを特徴とする。
【００１８】
上記課題を解決するための第２の発明は、受信メールのうち予め定義された演算対象範囲の文字列パターンの特徴量を算出する演算ステップと、前記演算ステップにより算出された前記受信メールの文字列パターンの特徴量と、記憶されている文字列パターンの特徴量との類否により、前記メールが悪意メールか否かを判断する判断ステップとを有することを特徴とする。
【００１９】
上記課題を解決するための第３の発明は、情報処理装置のプログラムであって、前記プログラムは情報処理装置に、受信メールのうち予め定義された演算対象範囲の文字列パターンの特徴量を算出する演算処理と、前記演算ステップにより算出された前記受信メールの文字列パターンの特徴量と、記憶されている文字列パターンの特徴量との類否により、前記メールが悪意メールか否かを判断する判断処理とを実行させることを特徴とする。
【発明の効果】
【００２０】
本発明によれば、データの一部を意図的に変更された場合であっても、悪意メールを検知することができる。その理由は、本発明の悪意メール検出装置が、比較対象として用いられるメールに含まれる文字列パターンの特徴量を記憶する記憶手段と、受信したメールに含まれる文字列パターンの特徴量を算出する演算手段とを備え、この演算手段により算出された受信メールの文字列パターンの特徴量と、予め記憶されている文字列パターンの特徴量との類否により、受信したメールが悪意メールか否かを判断する判断手段とを備えているからである。
【発明を実施するための最良の形態】
【００２１】
次に、本発明の第１の実施例について、図１、図２、及び図３の第１の実施例を示すブロック図を用いて説明する。
【００２２】
図１は、本実施例における悪意メール検出方式を用いた通信システムの一例を示す図である。検出装置５０は、端末５１、５２、５３と同一セグメントのネットワークで接続されている。検出装置５０は同一セグメント上に流れる全てのパケットを受信する。これは一般的なネットワークインタフェースカードではプロミスカスモードと呼ばれる設定で実現できる。検出装置５０は、端末５１、５２、５３のパケットのレイヤ７（ＯＳＩモデル第7層：以下「Ｌ７」ともいう）を分析する。検出装置５０は、分析結果をログへ記録する。
【００２３】
図２は、本実施例における悪意メール検出方式を用いた通信システムの他の一例を示す図である。通信装置６０、端末６１、６２、６３は、同一セグメントのネットワークで接続されている。尚、通信装置６０は、Ｌ７レベルのサービスを提供する通信装置であり、プロキシ、ロードバランサである。通信装置６０は、Ｌ２レベルの通信制御をするスイッチ・ハブ、Ｌ３レベルの通信制御をするルータ、Ｌ４レベルの通信制御をするファイアウォールであって構わない。この通信装置６０は、分析結果に応じてパケットを規制（パケットの廃棄・遮断）し、規制したパケットをログに記録する。
【００２４】
図３は、本発明における第１の実施例の構成を示すブロック図である。尚、本実施の形態は図１、図２のどちらの通信システムに適用させてもよい。
【００２５】
図３を見ると、本発明における第１の実施例による悪意メール検出方式は、プロトコル判定部１００と、特定部１１０と、対象文字指示部１６０と、ｎ−ｇｒａｍ処理部１２０と、判断部１３０と、検出部１４０と、記憶部１５０と、リファレンスパターン格納部１７０と、アクション処理部１８０とから構成される。
【００２６】
記憶部１５０は、記憶媒体であり、パケットの類似性を判断するにあたりユーザが予め指定した分析対象が記憶されている。記憶部１５０には、定義用テーブル１５１が含まれる。この定義用テーブル１５１には、検出装置５０または通信装置６０が何の類似性を分析するかがあらかじめプロトコル毎に指定される。例えば、ＴＣＰ２５番（ｓｍｔｐ）のパケットであれば、メールに含まれるＵＲＬの類似性を見るのか、マルウェア検知のために添付ファイルの類似性を見るのか、文字の出現頻度に基づいてメールを識別することでメールの類似性を見るのかが指される。また、定義用テーブル１５１では、計数単位の文字数（ｎ）が指定される。計数対象となる文字列を何文字で区切るかを指定する。例えば、計数対象となる文字列を１文字毎に区切って計数したい場合にはｎ＝１と設定される。
【００２７】
プロトコル判定部１００は、受信したパケットを受け取ると、パケットのＬ７プロトコルの判別をする。尚、ＴＣＰのポート番号などプロトコル判定に必要な情報が付加されているのであれば、パケットを再構築したストリームデータであっても、プロトコルの判別は可能である。ＴＣＰのポート番号が８０ならＨＴＴＰ、ＴＣＰのポート番号が２５ならＳＭＴＰと判別する。
【００２８】
特定部１１０は、プロトコル判定部１００で判定された結果と、定義用テーブル１５１とを参照し、パケットに含まれるデータの構文解析を行う。具体的には、定義用テーブル１５１に、プロトコルにＳＭＴＰが指定され、Ｃｏｎｔｅｎｔ−ｔｙｐｅにｔｅｘｔ／ｐｌａｉｎが指定されている場合、特定部１１０は、メールに含まれるＵＲＬの類似性を分析する旨の指定であると判断する。そして、特定部１１０は、ｈｔｔｐの文字を探し、ＵＲＬの開始位置と終了位置とを特定する。特定の結果として得られる計数（カウント）すべきデータ範囲は、実際に計数処理をするｎ−ｇｒａｍ処理部１２０へと通知される。
【００２９】
ここで、計数処理とは、文字列パターンに含まれる文字列数をカウントする処理である。文字列パターンとは文字列または文字によって構成される語句であり、「受信メールに含まれる文字列パターン」と「ユーザによって予め登録された文字列パターン」とに大別される。「受信メールに含まれる文字列パターン」とは、受信メール本文中、又は、受信メールの添付ファイル中の予め定義された範囲で指定される語句である。また、「ユーザによって予め登録された文字列パターン」とは、ユーザによって予め登録された比較対象として用いられるメールに含まれる特徴的な語句である。尚、文字列とは、この文字列パターンに含まれ、文字列パターンがｎ文字で区切られた１つ以上の文字である。尚、ｎ＝１の場合、１文字で区切られる単位は文字列ではなく厳密には文字となるが、以下実施例の説明では、ｎ＝１であっても説明の便宜のため文字列と表現する場合がある。
【００３０】
対象文字指示部１６０は、定義用テーブル１５１を参照し、計数対象となる文字を特定する。定義用テーブル１５１にアルファベットと記号とが計数対象として指定されていれば、対象文字指示部１６０は、計数対象の文字がアルファベット及び記号であると特定する。この特定された計数対象の文字は、ｎ−ｇｒａｍ処理部１２０へと通知される。
【００３１】
ｎ−ｇｒａｍ処理部１２０は、特定部１１０と対象文字指示部１６０とから通知されてきた計数対象の文字、計数対象範囲、文字列を区切る単位（ｎ）の情報に基づいて、受信したメールに含まれる文字列パターンの特徴量を算出する。ここで、特徴量とは、文字列パターンを構成する1文字以上の文字列の出現頻度の集合である。
【００３２】
ｎ−ｇｒａｍ処理部１２０において、特徴量の算出は以下のように行われる。まず、受信したメールに含まれる文字列パターンを、隣接するｎ文字の文字列で区切り、この区切られた文字列のそれぞれが、該文字列パターンの中に幾つ存在するかを示す出現回数をカウントする。さらに、このカウントされた値（出現回数）を、区切られた文字列の総数で除算することで、文字列毎の出現頻度が算出される。例えば、ｎ＝１の場合、文字列パターンがＵＲＬ（http://example3.com/ex1/top.html）であるとすると、ｎ−ｇｒａｍ処理部１２０による特徴量の算出結果は、図７の例に示されるような計数テーブルとして出力される。
【００３３】
尚、本実施例においては、計数対象となる計数単位の文字列を「ｎ文字の文字列として区切る」ｎ−ｇｒａｍ方式を採用し、ｎ文字の文字列として区切られた文字列の組合せがどのくらい出現するかの出現率を、区切られた文字ごとに調査するものとする。また、文字列を区切る単位（ｎ）は、定義用テーブルでユーザによって指定される。
【００３４】
リファレンスパターン格納部１７０は、悪意メールに含まれる文字列パターンを登録しておくための記憶領域である。具体的には、ユーザが、悪意メールと認定したメールに含まれる文字列パターンの特徴量をこの格納部に予め登録しておく。さらに、該文字列パターンを構成する各文字の出現頻度についても事前に算出し登録しておく。すなわち、図５の例に示されるように、文字列パターンを構成する各文字列と、各文字列の出現頻度とが対応付けられたリファレンスパターンを文字列パターン毎に複数格納しておく。
【００３５】
判断部１３０は、計数テーブルにおいて出現が確認されている文字列を含んだ出現パターンをもつリファレンスパターンが無いかどうか、リファレンスパターン格納部を参照し検索する。ここで、「出現が確認されている文字列」とは、出現頻度が０を超える文字であり、「出現パターン」とは、出現頻度が０を超える文字の組み合わせである。例えば、図７の計数テーブルにおける出現パターンは［ａ，ｃ，ｅ］であり、“ａ”、“ｃ”、または“ｅ”の文字を少なくとも含むリファレンスパターンをリファレンスパターン格納部１７０から抽出する。
【００３６】
判断部１３０によって計数テーブルで出現が確認された文字列を含むリファレンスパターンが見つかった場合、次に、検出部１４０は、計数テーブルと、リファレンスパターン格納部１７０に格納されているリファレンスパターンとを比較し、受信メールの文字列パターンの特徴量が、悪意メールと認定されたメールに含まれ予め登録された文字列パターンの特徴量と類似するか否かを判断する。
【００３７】
具体的には、検出部１４０は、計数テーブルに含まれる各文字列の出現頻度と、リファレンスパターンの各文字列の出現頻度との差分を文字列毎に計算する。そして、該文字列毎の差分の値の平均値と検出部が保持している閾値とを比較する。差分の値が閾値より小さい場合は、特徴量の類似性が確認できたとし、パケットの規制やログへの記録などのアクション処理を行う。
【００３８】
次に、図４に悪意メール検出方式の処理を示すフローチャートを用いて、本発明である悪意メール検出装置の処理の動作について説明する。
【００３９】
尚、ここでは、予め悪意メールとして登録したＵＲＬの文字列パターンと受信したパケット（メール）に含まれるＵＲＬとの類似性から悪意メールを検出する場合を例にとって説明する。
【００４０】
また、ここでは、メールに含まれるＵＲＬは図６に示されるような文字列パターンであるとする。また、計数単位の文字数ｎは１（ｎ＝１）と指定され、文字列パターンは1文字単位で区切られるものとして説明する。
【００４１】
ネットワーク上を流れるパケットを、検出装置が受信すると（ステップＳ１）、プロトコル判定部１００は、Ｌ７レベルでのプロトコル判定を行う（ステップＳ２）。すなわち、プロトコル判定部１００によって、パケットがＳＭＴＰプロトコルであると判定される。このプロトコル判定は、Ｌ２，Ｌ３，Ｌ４レベルで行わせるようにしてもよい。
【００４２】
次に、特定部１１０によって、パケットに含まれるデータが解析されて計数対象範囲が特定される。具体的には、特定部１１０によって定義用ファイル１５１が参照され、図６に示されるように、データ中のＣｏｎｔｅｎｔ−ｔｙｐｅ：ｔｅｘｔ／ｐｌａｉｎの記載がある場合、特定部１１０は、定義用テーブル１５１に定義されている情報に基づいてｈｔｔｐの文字を探し、ＵＲＬの開始位置と終了位置とをｎ−ｇｒａｍ処理部１２０へ通知する（ステップＳ３）。また、計数単位の文字数（ｎ＝１）をｎ−ｇｒａｍ処理部１２０へ通知する。
【００４３】
次に、対象文字指示部１６０によって、計数対象の文字が特定される。この場合、定義用ファイルには、アルファベットと記号が計数対象の文字として指定されているため、アルファベットと記号とが計数対象の文字であると特定される。この特定された情報はｎ−ｇｒａｍ処理部１２０へ通知される（ステップＳ４）。
【００４４】
続いて、特定部１１０と対象文字指示部１６０とからの指示に応答したｎ−ｇｒａｍ処理部１２０によって、文字の計数が行われる（ステップＳ２）。具体的には、受信したメールに含まれるＵＲＬが図６に示されるようにＵＲＬ（http://example3.com/ex1/top.html）であるので、ＵＲＬの先頭から順番に文字の個数をカウントされていく。ｈ：＋１（合計１），ｔ：＋１(合計１)，ｔ：＋１（合計２），ｐ：＋１（合計１）・・・の如く加算されていき、最終的なカウントの結果は、ａ：（合計１），ｂ：（合計０），ｃ：（合計１），ｄ（合計０），ｅ：（合計３）といったようなる。
【００４５】
最終的には、各文字の出現回数（カウンタ値）は、図７の計数テーブルのカウンタ項目欄に示されるような結果となる。さらに、正規化のため、計数対象の文字列パターンに含まれる全文字数で各文字の出現回数が除算され、出現頻度が算出される。例えば、本実施例の場合、図６のＵＲＬの文字数が全部で３２文字なので、各文字は３２で除算され、図７に示される計数テーブルの「出現頻度」の項目に示されるような文字列毎の出現頻度が得られる。上記算出された結果である出現回数、出現頻度の情報が、計数テーブルに記憶される。
【００４６】
次に、判断部１３０は、計数テーブルに記憶されており出現が確認されている文字列を少なくとも含む出現パターンを有するリファレンスパターンが無いかどうか、リファレンスパターン格納部１７０を検索する。この場合、図７に示されるように、出現が確認されている文字列（文字）は［ａ，ｃ，ｅ］であるので、“ａ”、“ｃ”、“ｅ”のいずれかを少なくとも含むリファレンスパターンをリファレンスパターン格納部１７０で検索する。ここでは、図５に示されるリファレンスパターンが抽出される。
【００４７】
判断部１３０の処理が終了後、計数テーブルに示された出現パターンに近いリファレンスパターンが見つかった場合には、検出部１４０は、計数テーブルの出現頻度の項目とリファレンスパターンの出現頻度の項目との差分の値を文字列毎に計算する（ステップＳ７）。さらに、検出部１４０は、この文字列毎に算出した差分の値の平均値と閾値とを比較し、差分の値の平均値が閾値より小さければ（ステップＳ８）、類似性有り（悪意メールを検出）とする。そして、アクション処理部３８０によって、パケットの規制やログへの記録等のアクション処理が行われる（ステップＳ９）。
【００４８】
上記のように構成された悪意メール検出装置によって、ＵＲＬの一部が意図的に変更された悪意メールであっても、検出することができる。
【００４９】
上記第１の実施例においては、判断部１３０が、メールに含まれる文字列パターンの出現パターンを含むリファレンスパターンを抽出した後、検出部１４０が、計数テーブルの頻度の項目とリファレンスパターンの頻度の項目との差分を計算し、該差分の平均値と保持する閾値との大小関係により悪意メールか否かを判断するよう構成させたが、上述したリファレンスパターンの抽出をせずに、判断部１３０と検出部１４０とを同時に機能させるようにしてもよい。すなわち、計数テーブルの頻度の項目とリファレンスパターンの頻度の項目との差分を計算し、該差分の平均値と保持する閾値との大小関係により、受信メールの文字列パターンと記憶されている文字列パターンとの類否を直接判断させるようにしてもよい。
【００５０】
また、上記第１の実施例においては、計数テーブルの出現頻度の項目とリファレンスパターンの出現頻度の項目との差分の値を文字列毎に算出し、この文字列毎の差分値の平均値と閾値とを比較し、該差分値の平均値が閾値よりも小さい場合に類似性有りと判断させるよう構成させたが、これに限ることはない。計数テーブルの出現頻度の項目とリファレンスパターンの出現頻度の項目との差分の値を文字列毎に算出した後、この算出した差分値の最大値と閾値とを比較し、該差分値の最大値が閾値よりも小さい場合に類似性有りと判断させるようにしてもよい。また、差分の値の偏りの度合いが所定の閾値よりも小さい場合に類似性有りと判断させてもよい。
【００５１】
上記第１の実施例においては、悪意メールに含まれる文字列パターンとしてＵＲＬに着目し、登録されているＵＲＬとメールに含まれるＵＲＬとの類似性に基づいてスパムメールか否かを判断する場合を例にとって説明したが、本発明によれば、添付ファイルの類似性によりマルウェアを検知させるようにすることもできる。
【００５２】
次に、本発明の第２の実施例について、図９の第２の実施例を示すブロック図を用いて説明する。
【００５３】
第２の実施例の悪意メール検出装置は、特定部２１０と、ｎ−ｇｒａｍ処理部２２０と、判断部２３０と、検出部２４０と、対象文字指示部２６０と、リファレンスパターン格納部２７０と、アクション処理部２８０とを有する。
【００５４】
特定部２１０は、定義用テーブル２５１を参照して、受信メールの添付ファイルに含まれる予め定義された計数対象範囲をｎ−ｇｒａｍ処理部２２０に指示する。
【００５５】
ｎ−ｇｒａｍ処理部２２０は、特定部２１０及び対象文字指示部２６０により指示された演算対象範囲の文字列パターンについて、特徴量を算出する。
【００５６】
対象文字指示部２６０は、定義用テーブル２５１を参照し、添付ファイルに含まれるデータ中の計数対象となる文字を特定する。
【００５７】
リファレンスパターン格納部２７０は、悪意メール（マルウェア）に含まれる文字列パターンを登録しておくための記憶領域である。登録する文字列パターンは、通常のメールには含まれずマルウェアだけに含まれるような特徴的な文字列パターンとすることが望ましい。さらに、該文字列パターンを構成する各文字の出現頻度についても事前に算出し登録しておく。尚、その他構成部分の機能については第１の実施例の場合と同様である為、詳細な説明は省略する。
【００５８】
次に、第２の実施例における動作について説明する。
【００５９】
ここでは、定義用ファイルには、「プロトコル：ＳＭＴＰ」及び「Ｃｏｎｔｅｎｔ−ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ」の条件の場合に、「添付ファイルの全ての範囲が計数対象」「全ての文字が計数対象」である旨の定義がされているものとする。また、ここでも、計数単位の文字数ｎが１（ｎ＝１）と指定された場合を例にとって説明する。
【００６０】
プロトコル判定部２００によるプロトコル判定の結果がＳＭＴＰであり、Ｃｏｎｔｅｎｔ−ｔｙｐｅにａｐｐｌｉｃａｔｉｏｎが記されていることを確認した特定部２１０は、添付ファイルに相当するデータの部分において、計数対象範囲（どの範囲を計数すべきか）を、定義用ファイルを参照してｎ−ｇｒａｍ処理部２２０へ指示する。
【００６１】
対象文字指示部２６０は、ｎ−ｇｒａｍ処理部２２０に全ての文字を計数するよう指示する。ｎ−ｇｒａｍ処理部２２０は、受信メールの添付ファイルにおける演算対象範囲の文字列パターンについて、特徴量を算出し、算出した結果を計数テーブルに記憶する。
【００６２】
続いて、判断部２３０は、計数テーブルに記憶されており出現が確認されている文字列を含む出現パターンを有するリファレンスパターンが無いかどうか、リファレンスパターン格納部２７０を検索する。
【００６３】
判断部２３０の処理が終了後、計数テーブルに示された出現パターンに近いリファレンスパターンが見つかった場合には、検出部２４０は、計数テーブルの出現頻度の項目とリファレンスパターンの出現頻度の項目との差分の値を文字列毎に計算する。さらに、検出部２４０は、この文字列毎に算出した差分の値の平均値と閾値とを比較し、差分の値の平均値が閾値より小さければ、類似性有り（マルウェア検出）と判断する。そして、アクション処理部２８０によって、パケットの規制やログへの記録等のアクション処理が行われる。
【００６４】
上記のように構成させた第２の実施例では、マルウェアの添付メールに含まれる文字列パターンを構成する文字列の出現頻度の集合をリファレンスパターン格納部に予め格納しておき、受信メールの添付ファイルに含まれる文字列パターンを構成する文字列の出現頻度の集合との類否に基づいて悪意メールか否かを判断する判断手段を備えているため、メールに含まれる添付ファイルのデータの一部が変更されたようなマルウェアであっても検出することが可能となる。
【００６５】
さて、メールの種類毎に文字の出現頻度には特徴がある。この特徴に着目すれば、本発明の検出装置をメールの識別装置として機能させることも可能である。
【００６６】
次に、本発明の第３の実施例について、図１０の第３の実施例を示すブロック図を用いて説明する。
【００６７】
第３の実施例においては、特定部３１０と、ｎ−ｇｒａｍ処理部３２０と、判断部３３０と、検出部３４０と、対象文字指示部３６０と、リファレンスパターン格納部３７０と、アクション処理部３８０とを有する。
【００６８】
特定部３１０は、定義用テーブル３５１を参照して、受信メールに含まれる予め定義された計数対象範囲をｎ−ｇｒａｍ処理部３２０に指示する。
【００６９】
対象文字指示部３６０は、定義用テーブル３５１を参照し、添付ファイルに含まれるデータ中の計数対象となる文字を特定する。
【００７０】
ｎ−ｇｒａｍ処理部３２０は、特定部３１０及び対象文字指示部３６０により指示された演算対象範囲の文字列パターンについて、特徴量を算出する。
【００７１】
リファレンスパターン格納部３７０は、メール種別を特定可能な程度に特徴的な文字列パターンを予め登録しておくための記憶領域である。登録対象の文字列パターンは、メールの種別を特定するのにふさわしい特徴的な文字列パターンとすることが望ましい。さらに、該文字列パターンを構成する文字列毎の出現頻度についても事前に算出し登録しておく。尚、その他構成部分の機能については第１の実施例の場合と同様である為、詳細な説明は省略する。
【００７２】
尚、上記第１及び第２の実施例においては、悪意メールと認定されたメールを予め登録しておき、受信メールの文字列パターンを構成する各文字の出現頻度と、記憶されている文字列パターンを構成する各文字の出現頻度との差分を算出し、この文字毎に算出された差分値の平均値が所定の閾値よりも小さい場合に受信メールが悪意メールと判断する構成をとったが、これに限ることはない。悪意メールでないと認定されたメールを予め登録しておき、受信メールの文字列パターンを構成する各文字の出現頻度と、記憶されている文字列パターンを構成する各文字の出現頻度との差分値の平均値が所定の閾値よりも大きい場合に、前記受信メールが悪意メールと判断する構成をとることもむろん可能である。
【００７３】
次に、第３の実施例における動作について説明する。
【００７４】
ここでは、定義用ファイルには、「プロトコル：ＳＭＴＰ」及び「Ｃｏｎｔｅｎｔ−ｔｙｐｅ：ｔｅｘｔ／ｐｌａｉｎ」の条件の場合に、「メールに含まれるデータの１バイト目から１００バイト目までが計数対象」「全ての文字が計数対象」である旨の定義がされているものとする。また、ここでも、計数単位の文字数ｎが１（ｎ＝１）と指定された場合を例にとって説明する。
【００７５】
プロトコル判定部３００によるプロトコル判定の結果がＳＭＴＰであり、Ｃｏｎｔｅｎｔ−ｔｙｐｅにｔｅｘｔ／ｐｌａｉｎが定義用ファイル３５１に記されていることを確認した特定部３１０は、定義用ファイルを参照し、計数対象範囲がメールに含まれるデータの１バイト目から１００バイト目までを計数範囲とするようにｎ−ｇｒａｍ処理部３２０へ指示する。
【００７６】
対象文字指示部３６０は、ｎ−ｇｒａｍ処理部３２０に全ての文字（アルファベット・数字・記号・漢字・カナ等）を計数するよう指示する。ｎ−ｇｒａｍ処理部３２０は、計数した結果を計数テーブルに記憶する。
【００７７】
続いて、判断部３３０は、計数テーブルに記憶されており出現が確認されている文字列を含む出現パターンを有するリファレンスパターンが無いかどうか、リファレンスパターン格納部３７０を検索する。
【００７８】
判断部３３０の処理が終了後、計数テーブルに示された出現パターンに近いリファレンスパターンが見つかった場合には、受信したメールの種類は、該リファレンスパターンに登録されたメールの種類と同一の種類あると識別することができる。
【００７９】
上記のように構成させた第３の実施例では、メールの種類を特定可能な文字列パターンと該文字列パターンを構成する文字列の出現頻度の集合とを対応付けてリファレンスパターン格納部に予め格納しておき、受信メールに含まれる文字列パターンを構成する文字列の出現頻度の集合との類否を調べる判断手段を備えているため、受信メールがどのような種別のメールであるのか、メールを識別することが可能となる。
【００８０】
次に、第４の実施例について、図１１の全体ブロック図と、図１２のブロック図とを用いて説明する。
【００８１】
図１１を見ると、第４の実施例における構成では、第１から第３の実施例における構成に加えてメモリ解放機能部４９０を更に有する。メモリ解放機能部４９０は、所定のストリームの構築規則に従って、受信したメールから少なくとも一つ以上のストリームを構築する。ここで、「所定のストリームの構築規則」とは、例えば、「受信メールのパケットを一定のサイズになるまで連結してストリームを構築する」、或いは、「受信データのｓｍｔｐコマンドに含まれる改行コードを確認するまでストリームを構築する」といった、ストリームを構築するために予め定義された規則である。そして、この構築したストリームを管理し、ｎ−ｇｒａｍ処理部４２０による特徴量の算出が終了すると、そのストリームの管理に使用されているメモリ領域を解放する。
【００８２】
ここで構築されたストリームは、特定部４１０によるデータの構文解析、及び、ｎ−ｇｒａｍ処理部４２０による計数処理・特徴量算出処理の処理単位となる。
【００８３】
特定部４１０は、メモリ解放機能部４９０から指示を受けると、構文解析を開始する。このとき、特定部４１０は、メモリ解放機能部４９０から渡されたストリームのデータを構文解析の処理単位とする。構文解析の処理の後、特定部４１０は、ストリームを構文解析の結果とともにｎ-ｇｒａｍ処理部４２０へ渡す。
【００８４】
ｎ−ｇｒａｍ処理部４２０は、特定部４１０から渡されたストリーム毎に特徴量を算出する。ストリーム毎の特徴量の算出処理が終了すると、終了した旨をメモリ解放機能部４９０に通知する。その他、特定部４１０、ｎ−ｇｒａｍ処理部４２０は、第１から第３の実施例で詳述した機能を有するが、ここでは詳細な説明を省略する。また、他の構成部の機能についても、第１から第３の実施例における機能と同一であるため、ここでは詳細な説明を省略する。
【００８５】
続いて、メモリ解放機能部４９０の内部構成について、図１２のブロック図を用いて詳細に説明する。
【００８６】
メモリ解放機能部４９０は、セッション管理部４０００と、ストリーム再構築処理部４００１と、プロトコル状態遷移管理部４００２と、指示部４００３と、セッション管理テーブル４０１０と、ストリーム管理テーブル４０１１と、プロトコル状態遷移管理部４０１２とを有する。
【００８７】
セッション管理部４０００は、プロトコル判定部４００を介してメールのパケットを受信すると、受信したメールによるセッションが新規であるのか否かを判断する。そして、新規なセッションであると判断された場合には、その受信メールによるセッションを特定するための識別情報であるセッションＩＤを付与する。
【００８８】
また、セッション管理部４０００は、受信メールのパケットによる新規なセッションの接続情報を、セッションＩＤに関連付けてテーブルに登録する。更に、不要になったセッションの接続情報をテーブルから削除する。ここで、接続情報とは、セッション（接続）を特定するための情報である。例えば、送信元・送信先ＩＰアドレス，送信元・送信先ポート番号，プロトコル等の情報である。この接続情報の登録・削除は、セッション管理部４０００が有するセッション管理テーブル４０１０に対して行う。
【００８９】
また、セッション管理部４０００は、セッション管理テーブル４０１０に対し登録・削除を終えたパケットを、ストリーム再構築処理部４００１に渡す。
【００９０】
ここで、新規なセッションであるか否かの判断の方法であるが、送信元ＩＰアドレス，送信先ＩＰアドレス，送信元ポート番号，送信先ポート番号，及びプロトコルの少なくとも５タプルを参照して行われる。すなわち、セッション管理部４０００は、到着したパケットの５タプルを参照し、セッション管理テーブル４０１０に未登録であれば、受信パケットの接続情報を新規セッションとして登録する。既にセッションが登録されている場合には登録処理は行われない。また、指示部４００３からの指示を受けて不要になったセッションの接続情報を削除し、メモリ領域を解放する。
【００９１】
ストリーム再構築処理部４００１は、ストリームの構築規則に従って、セッション管理部４０００から受信したメールのパケットに基づいて、少なくとも一つ以上のストリームを新たに構築する。また、構築したストリームに、ストリームを特定するための識別情報であるストリームＩＤを付与する。ここで、ストリーム再構築処理部４００１は、ストリーム管理のために設けられたストリーム管理テーブル４０１１を用いて、ストリームＩＤが付与されたストリームを管理する。ストリーム再構築処理部４００１は、この付与したストリームＩＤをストリームの情報（ストリームのデータサイズ，先頭ポインタのアドレス等）と関連付けてストリーム管理テーブル４０１１に登録し、更に、セッションＩＤと対応付けて管理する。
【００９２】
また、ストリーム再構築処理部４００１は、指示部４００３からの指示、及びストリームＩＤの通知に応答して、構築したストリームを管理する為のメモリ領域を解放する。具体的には、通知されたストリームＩＤに対応するストリームの情報を、ストリーム管理テーブル４０１１から削除する。
【００９３】
図１３にはセッション管理テーブルの例が、図１４にはストリーム管理テーブルの例が示される。ストリーム再構築処理部４００１は、メールを受信すると、図１３の例で示されるセッション管理テーブル４０１０を参照し、受信メールのパケットの接続情報に基づいてセッションＩＤを調べる。そして、図１４の例で示されるストリーム管理テーブル４０１１を参照し、取得したセッションＩＤに対応する「ストリーム構築フラグ」の値（以下、フラグ値ともいう）に従って、ストリームを構築する。
【００９４】
ここで、ストリーム構築フラグとは、ストリーム構築の際に構築単位を決める際に参照される識別子である。メール本文のデータを受信する迄の間は、ストリーム構築フラグのフラグ値は「０」に設定される。メール本文のデータを受信すると、フラグ値「１」が設定される。このストリーム構築フラグは、ｓｍｔｐコマンドの遷移の通知を受けたストリーム構築処理部４００１によって設定される。
【００９５】
ストリーム再構築処理部４００１は、ストリーム構築フラグの値が「０」の場合には“改行コード”まで、「１」の場合には“予め定められたサイズか、又は、メール本文終了（「．」行の受信）”まで、ストリームを構築する。そして、ストリーム再構築処理部４００１は、構築したストリームを、プロトコル状態遷移管理部４００２に渡す。
【００９６】
プロトコル状態遷移管理部４００２は、ストリーム再構築処理部４００１で構築されたストリームを受け取ると、プロトコルの状態遷移を追跡し、プロトコルの状態遷移のステータスを管理する。さらに、受け取ったストリームを特定部４１０に渡す。具体的には、「フラグ値０」の状態で構築されたストリームをストリーム再構築処理部４００１から受信すると、プロトコルの状態遷移の追跡を開始する。
【００９７】
この遷移の追跡であるが、プロトコル遷移情報（ｓｍｔｐコマンド）が登録されたプロトコル状態遷移管理テーブル４０１２を用いて行われる。具体的には、プロトコル状態遷移管理部４００２は、受信データに含まれるｓｍｔｐコマンドと、プロトコル状態遷移管理テーブル４０１２に予め登録されたｓｍｔｐコマンドとの一致・不一致に基づいて追跡が行われる。受信データに含まれるｓｍｔｐコマンドと、プロトコル状態遷移管理テーブル４０１２に予め登録されたｓｍｔｐコマンドとが一致した場合、プロトコルの状態（ｓｍｔｐコマンドの状態）の遷移の追跡を続ける。尚、一致しない場合には、この遷移の追跡を中断し、更には、該受信メールからのストリーム構築処理も中止する。これにより、不正なプロトコルコマンドによるストリームについては分析の対象から外される。明らかに不正なプロトコルコマンドによるストリームについてまで構築・分析の対象とする必要は無いからである。
【００９８】
一方、「フラグ値１」の状態でストリームをストリーム再構築処理部４００１から受信すると、プロトコル状態遷移管理部４００２は、プロトコルの状態（ｓｍｔｐコマンドの状態）遷移の追跡は行わずに該ストリームを特定部４１０に渡す。「フラグ値１」の場合は、既に「ＤＡＴＡ」コマンドに遷移した状態であることが自明であり、敢えて遷移を追跡する必要がないからである。
【００９９】
また、プロトコル状態遷移管理部４００２は、プロトコル状態遷移管理テーブル４０１２の情報とストリームのデータとを照合し、「ＤＡＴＡ」への遷移を確認すると、遷移の完了をストリーム再構築処理部４００１に通知する。この通知は、指示部４００３を介して行われる。更に、遷移の追跡を終えると、指示部からの通知に応答して、プロトコルの状態遷移のステータスを示す情報をプロトコル状態遷移管理テーブル４０１２から削除する。
【０１００】
指示部４００３は、各部（セッション管理部、ストリーム再構築処理部、プロトコル状態遷移管理部）と連携しメモリ解放の制御をする。又、各部に対し、ストリームの構築や構文解析の開始を指示する。具体的には、プロトコル状態遷移管理部４００２より、「ＤＡＴＡ」への遷移完了の通知を受けると、ストリーム再構築処理部４００１に対し、“予め定められたサイズ（又は、メール本文終了（「．」行の受信））”までストリームを構築するよう指示を通知する。
【０１０１】
また、指示部４００３は、予め定められたサイズになるまでストリーム構築が完了した旨の通知をストリーム再構築処理部４００１から受けとると、特定部４１０に対して構文解析の開始を指示する。更に、指示部４００３は、「特徴量の算出処理」が終了した旨の通知をｎ−ｇｒａｍ処理部４２０から受け取ると、これに応答し、構築したストリームによるセッションを解放するようストリーム再構築処理部４００１へ指示を通知する。尚、この指示の通知の際、構築したストリームに付与されたストリームＩＤもあわせて通知される。
【０１０２】
この通知を受けたストリーム再構築部４００１では、通知されたストリームＩＤに対応するセッションＩＤに関連する情報をストリーム管理テーブル４０１１から削除する。
【０１０３】
更に、指示部４００３は、構築したストリームに付与されたストリームＩＤを含むセッションＩＤに関連付けられた情報の削除が完了した旨の通知をストリーム再構築処理部４００１から受信すると、受信したメールのパケットの接続情報をセッション管理テーブル４０１０から削除する旨の指示をセッション管理部４０００に対し通知する。同様に、プロトコルの遷移情報をプロトコル状態遷移管理テーブル４０１２から削除する旨の指示をプロトコル状態遷移管理部４００２に対して通知する。この指示の通知の際も、ストリームＩＤがあわせて通知される。
【０１０４】
この通知を受けたセッション管理部４０００、及びプロトコル状態遷移管理部４００２では、通知されたストリームＩＤに関連して登録された情報を、セッション管理テーブル４０１０、プロトコル状態遷移管理テーブル４０１２からそれぞれ削除する。
【０１０５】
次に、第４の実施例における悪意メール検出装置の動作について、図１５，図１６のメモリ解放処理を示すフローチャートを用いて説明する。
【０１０６】
尚、本実施例では、メールのパケットに加えてメール以外のパケットが混在するネットワーク環境に設置された本装置が、ｓｍｔｐプロトコルのパケットを分析の対象として処理する場合を例にとって説明する。
【０１０７】
また、本実施例では、受信したメール（以下、受信メールＡとも記載する）には、セッションＩＤ“０００１”が付与されるものとする。また、以下では、“送信元ＩＰアドレス，送信先ＩＰアドレス，送信元ポート番号，送信先ポート番号，プロトコル番号”が、それぞれ“ｓ１，ｄ１，ｓｐ１，ｄｐ１、ＴＣＰ２５”であるものとして説明する。
【０１０８】
また、本実施例では、メール本文のデータの受信後、５００バイトのデータ量に相当するストリームを構築し、この５００バイトのストリームを処理単位として特徴量を算出する場合を例にとって説明する。
【０１０９】
また、以下では、“改行コードを確認するまで”構築したストリームに対しては、ストリームＩＤ“ｓｔｒｅａｍ１〜ｓｔｒｅａｍ４”が付与され、“一定サイズ（５００バイト）になるまで”構築されたストリームには、ストリームＩＤ“ｓｔｒｅａｍ５”が付与されるものとする。尚、一定サイズは、ここでは５００バイトであるとして説明するが、５００バイトに限る必要はない。例えば、予めデータサイズを３００バイトと設定しておき、３００バイトのデータ量に相当するストリームを構築し、この３００バイトの処理単位についての特徴量算出が終了した後でメモリ領域を解放するように構成させても構わない。
【０１１０】
また、本実施例は、前述の図１の例に示される検出装置、図２の例に示される通信装置のどちらに適用させても構わない。
【０１１１】
さて、パケットのストリームが本装置に流入すると、プロトコル判定部４００は、パケットのＬ７プロトコルの判定をする。プロトコル判定部４００による判定の結果、ＳＭＴＰプロトコルであると判定されたストリームのパケットは、メモリ解放機能部４９０に渡される。このパケットをメモリ解放機能部４９０のセッション管理部４０００で受信すると（ステップＴ２）、セッション管理部４０００は、受信したパケットによるセッションが新規か否かを判定する。具体的には、到着したパケットの５タプル（送信元ＩＰ、送信先ＩＰ、送信元ポート、送信先ポート、プロトコルの組）の情報（以下、接続情報ともいう）を参照し、セッション管理テーブル４０１０に登録されていない場合（ステップＴ３：Ｎｏ）、新規なセッションであるかどうかが判定される。
【０１１２】
新規なセッションであると判定された場合（ステップＴ３：Ｎｏ）、このセッションには新たなセッションＩＤがセッション管理部４０００によって付与される。ここでは、“０００１”が付与される。更に、ストリーム再構築処理部４００１によって、セッションＩＤ“０００１”に対応するストリーム構築フラグの値が「０」に設定される（ステップＴ５）。
【０１１３】
こうして、図１３に示されるように、付与されたセッションＩＤ“０００１”と該セッションによる接続情報とが関連付けられ、セッション管理テーブル４０１０に登録される。尚、既に登録されている場合には登録は行われない（ステップＴ３：Ｙｅｓ）。
【０１１４】
続いて、ストリーム再構築処理部４００１は、ストリーム構築フラグを参照し、ストリームの構築を開始する。ここでは、フラグ値「０」であるので、受信データに改行コードがある迄、ストリームが構築される（ステップＴ８）。
【０１１５】
ここで構築されたストリームは、プロトコル状態遷移管理部４００２に渡される。そして、プロトコル状態遷移管理部４００２では、受信したメールのパケットが正規なプロトコルコマンドを含むかどうかチェックする（ステップＴ９，１０）。このチェックであるが、具体的には、受信データに含まれるｓｍｔｐコマンドと、プロトコル状態遷移管理テーブル４０１２に予め登録されたｓｍｔｐコマンドとが一致するかどうかによって行われる。
【０１１６】
予め登録されたｓｍｔｐコマンドと一致しない場合、プロトコル状態遷移管理部４００２は、受信したメールのパケットが、不正なプロトコルコマンドを含むパケットであると判断する。そして、ストリームの構築を終了し、次のパケットの受信処理に移る（ステップＴ１０：Ｎｏ，ステップＴ３０）。
【０１１７】
一致する場合、プロトコル状態遷移管理部４００２は、受信したメールのパケットが、正しいプロトコルコマンドを含むパケットであると判断する。そして、セッション管理テーブル４０１０を参照してストリームを構築するようにストリーム再構築処理部４００１に指示を通知する。ここでは、ストリーム構築フラグが「０」であるので、「改行コード」を確認するまで受信メールＡのパケットは連結され、ストリームが構築される（ステップＴ１１）。構築されたストリームには、ストリーム再構築処理部４００１によってストリームＩＤが付与される（ステップＴ１２）。ここでは、ストリームＩＤ“ｓｔｒｅａｍ１”が付与される。
【０１１８】
また、このとき構築されたストリームは、プロトコル状態遷移管理部４００２に渡され、プロトコルの状態遷移が追跡される（ステップＴ１３）。
【０１１９】
ここで、「改行コード」毎にストリームを構築する理由であるが、プロトコルのコマンドをプロトコル状態遷移管理部４００２に正しく認識させるためである。ＳＭＴＰは、コマンドの文字列の後に改行コードがある。従って、「改行コード」までストリームを構築するようにすれば、ＳＭＴＰのコマンドが複数のパケットにまたがる場合でも、正確にプロトコルコマンドを認識させることができる。例えば、受信したパケットが、１パケット目：［ＨＥ］，２パケット目：［ＬＯ
ｅｘａｍｐｌｅ．ｃｏ．ｊｐ”改行コード”］である場合に、”改行コード”までストリームを構築すれば、１パケット目と２パケット目を連結して「ＨＥＬＯ ｅｘａｍｐｌｅ．ｃｏ．ｊｐ”改行コード”」のデータを得ることができる。これによって、"ＨＥＬＯ"というｓｍｔｐコマンドの存在が確認できる。尚、ＳＭＴＰのコマンドが１パケットに収まっているような場合には、パケットは連結しない。パケットを連結せずともプロトコルコマンドの確認ができるからである。
【０１２０】
こうして、受信したパケットに基づいて、「改行コード」までのパケットがストリームとして構築される処理が、「ＤＡＴＡ」コマンドを受信するまで繰返し行われる（ステップＴ８〜ステップＴ１１）。その結果、ここでは、“「ＨＥＬＯ」コマンド”，“「ＭＡＩＬ  ＦＲＯＭ」コマンド”，“「ＲＣＰＲ  ＴＯ」コマンド”，“「ＤＡＴＡ」コマンド”を含む４つのストリームが、ストリーム再構築処理部４００１によって構築される。この構築されたストリームにはストリームＩＤ“ｓｔｒｅａｍ１〜ｓｔｒｅａｍ４”がストリーム再構築処理部４００１によって付与され、ストリーム管理テーブル４０１１でセッションＩＤ毎に管理される。具体的には、付与された“ｓｔｒｅａｍ１〜ｓｔｒｅａｍ４”は、セッションＩＤ”０００１“に対応付けられ、他のストリームの情報とともにストリーム管理テーブルで管理される。尚、このとき、セッションＩＤ”０００１“に対応するフラグ値は０である。
【０１２１】
また、プロトコル状態遷移管理部４００２では、プロトコルの状態の遷移を追跡しており（ステップＴ１３）、プロトコルコマンドであるｓｍｔｐコマンドが“「Ｄａｔａ」コマンド”に遷移したか否かがチェックされる（ステップＴ１４）。
【０１２２】
ここで、プロトコル状態遷移管理部４００２による「ＤＡＴＡ」コマンドへの遷移の確認は、具体的には以下のように行われる。
【０１２３】
プロトコル状態遷移管理テーブル４０１２には、予めプロトコル遷移情報が登録されている。例えば、追跡するプロトコルの遷移情報として、「ＨＥＬＯ」−＞「ＭＡＩＬ  ＦＲＯＭ」−＞「ＲＣＰＴ  ＴＯ」−＞「ＤＡＴＡ」のコマンドが登録されている。プロトコル状態遷移管理部４００２は、このプロトコル状態遷移管理テーブル４０１２に登録されたコマンドの情報と、トラフィックを構成するパケットに含まれるデータのコマンド情報との一致・不一致を調べることで、プロトコルの状態が「ＤＡＴＡ」コマンドに遷移したかどうかを確認する。
【０１２４】
「ＤＡＴＡ」コマンドへの遷移が確認されるまでは、フラグ値は０であり、ストリーム再構築処理部４００１は、受信メール内の改行コードを確認するまでストリームを構築する処理をする。
【０１２５】
プロトコル状態遷移管理部４００２によって「ＤＡＴＡ」コマンドへの遷移が確認されると（ステップＴ１４：Ｙｅｓ）、プロトコル状態遷移管理部４００２は、「ＤＡＴＡ」コマンドへの遷移完了をストリーム再構築処理部４００１に通知する。この通知は、指示部４００３を介して行われる。この通知を受けて、ストリーム再構築処理部４００１は、メール本文のデータ受信がはじまったことを認識する。そして、ストリーム再構築処理部４００１は、ストリーム構築フラグを０から１に更新／設定する（ステップＴ１５）。
【０１２６】
ストリーム構築フラグを１に設定したストリーム再構築処理部４００１では、続いて、構築するストリームサイズを変更する。これにより、”「改行コード」までストリーム構築する”処理から”５００バイト又はメール本文終了まで（「．」行を受信するまで）ストリームを構築する”処理へと切り替わる（ステップＴ１６）。
【０１２７】
上述の如く構築処理を切り替え、ストリームサイズを変更させる目的は以下の通りである。すなわち、「ＤＡＴＡ」コマンドを受信後に受信するデータは、メール本文のデータになるが、“「改行コード」までストリームを構築する”構築処理のままでは、メール本文１行だけしかストリームを構築できないことになってしまう。「ＤＡＴＡ」コマンド受信後においては、一定サイズ（実施例では５００バイト）か、メール本文終了まで（「．」行を受信するまで）ストリームを構築し、分析処理に必要な処理単位を確保する必要がある。
【０１２８】
さて、ストリーム再構築処理部４００１によって、５００バイト又はメール本文終了（「．」行の受信）までのストリーム構築が終了すると（ステップＴ１７：Ｙｅｓ）、この構築されたストリームにはストリームＩＤ“ｓｔｒｅａｍ５”が付与される（ステップＴ１８）。この“ｓｔｒｅａｍ５”が付与されたストリームは、プロトコル状態遷移管理部４００２を介して特定部４１０に渡される。また、「５００バイト迄ストリームの構築が終了」した旨の通知が、ストリームＩＤ“ｓｔｒｅａｍ５”とともに、指示部４００３に送信される。このときのストリーム管理テーブルの登録状況は、図１４の例で示される。
【０１２９】
このストリーム構築終了の通知を受けた指示部４００３は、特定部４１０に対し、該ストリームのデータの構文解析の開始を伝える指示と、ストリームＩＤ“ｓｔｒｅａｍ５”とを通知する（ステップＴ１９）。この通知に応答した特定部４１０では、５００バイトのデータ量のストリームを処理単位として、データの構文解析を開始する（ステップＴ２０）。更に、ｎ−ｇｒａｍ処理部４２０によって、５００バイトのデータ量のストリームを処理単位として、通知されたストリームＩＤ“ｓｔｒｅａｍ５”のストリームについての特徴量が算出される（ステップＴ２２）。
【０１３０】
ｎ−ｇｒａｍ処理部４２０による特徴量の算出処理が終了すると（ステップＴ２３：Ｙｅｓ）、ｎ−ｇｒａｍ処理部４２０から処理完了通知が、指示部４００３を介してストリーム再構築処理部４００１に送出される（ステップＴ２４）。このとき、ストリームＩＤ“ｓｔｒｅａｍ５”もストリーム再構築処理部４００１に通知される（ステップＴ２５）。
【０１３１】
この処理完了通知を受信したストリーム再構築処理部４００１では、通知されたストリームＩＤ“ｓｔｒｅａｍ５”を管理するためのメモリ領域を解放する（ステップＴ２６）。このとき、ストリームＩＤ“ｓｔｒｅａｍ５”に対応するストリームと同じセッションＩＤ“０００１”をもつ他のストリーム（ストリームＩＤ“ｓｔｒｅａｍ１〜４”に対応するストリーム）についても、ストリーム管理の為のメモリ領域が解放される（ステップＴ２７）。こうして、ストリームＩＤ“ｓｔｒｅａｍ５”に対応するセッションＩＤ“０００１”に関連付けられたストリームＩＤ“ｓｔｒｅａｍ１〜ｓｔｒｅａｍ５”について、これらのストリームＩＤに対応するストリームの情報が、ストリーム管理テーブル４０１１から削除されることになる。
【０１３２】
続いて、ストリーム再構築処理部４００１は、メモリ解放が完了した旨の完了通知を、ストリームＩＤとあわせて指示部４００３に返信する。
【０１３３】
更に、メモリ解放の完了通知を受けた指示部４００３では、残りのセッション管理テーブル４０１０及びプロトコル状態遷移管理テーブル４０１２の該当セッションについても削除するように、セッション管理部４０００及びプロトコル状態遷移管理部４００２に対して指示を通知する。
【０１３４】
この通知を受信したセッション管理部４０００では、通知されたストリームＩＤのストリームによるセッションを管理するのに使用されているメモリ領域を解放する（ステップＴ２８）。具体的には、セッションＩＤ“０００１”、及びセッションＩＤ“０００１”に関連付けられた接続情報がセッション管理テーブル４０１０から削除される。
【０１３５】
同様に、指示部４００３からの通知を受信したプロトコル状態遷移管理部４００２も、通知されたストリームＩＤのストリームを管理するのに使用されているメモリ領域を解放する（ステップＴ２８）。具体的には、構築したストリームを構成する各パケットについて追跡されたプロトコルの状態遷移のステータスを示す情報が、プロトコル状態遷移管理テーブル４０１２から削除される。以上によりメモリ領域の解放が完了する（ステップＴ２９）。
【０１３６】
上記のように構成させた第４の実施例では、メール１通分のデータが取得されるのを待たずに、ストリームの構築規則に従って受信メールから構築したストリームのデータが揃った時点で、データの構文解析を開始することができる。従って、悪意メールの検出に要する時間を一層短縮化し、悪意メール検出処理を効率化することができる。
【０１３７】
更に、上記第４の実施例では、メール１通分のデータが揃うのを待たずに、ストリームの構築規則に従って受信メールから構築したストリームのデータが揃った時点でデータの構文解析を開始する。そして、ｎ−ｇｒａｍ処理部による特徴量の算出が終了した後で、この処理単位のストリームの管理に使用されているメモリ領域を解放する。従って、搭載するメモリを小容量化することができ、装置のコストを抑えることができる。
【０１３８】
更に、上記第４の実施例では、メモリ解放手段におけるプロトコル状態遷移管理部がプロトコルの状態の遷移を追跡し、ｓｍｔｐコマンドが「ＤＡＴＡ」コマンドに遷移したことが確認された後に、一定サイズまでストリームを構築している。この為、プロトコルに違反したパケットが分析の対象にならず、正しいプロトコルにのっとったパケットのみが分析の対象となる。従って、分析対象の絞込みができ、更なる処理の効率化が図れる。
【０１３９】
尚、本実施例では、処理効率の観点から、メール本文のデータについて構築したストリームだけを特徴量の算出対象としたが、これに限る必要はない。改行コードまで構築されたストリームも含めて特徴量の算出対象とすることで、メールヘッダを分析対象に含めるようにしてもよい。例えば、ｓｔｒｅａｍ５のストリームに限らず、ｓｔｒｅａｍ１〜５の全てのストリームについて特徴量を算出し、特徴量の算出後にこれらのストリームを管理するのに使用されているメモリ領域を解放するように構成させてもよい。
【０１４０】
また、本実施例では、改行コードまでストリームを構築した後、メール本文のデータが一定サイズになる迄ストリームを構築したが、改行コードまでのストリーム構築処理は省略しても構わない。例えば、「ＤＡＴＡ」コマンドの受信有無のみを監視し、「ＤＡＴＡ」コマンドの受信を受けてメール本文のデータが一定サイズになる迄ストリームを構築するように構成させてもよい。
【０１４１】
尚、本実施例では、ｎ−ｇｒａｍ処理部による特徴量の算出終了後、ストリーム管理テーブルで管理されているセッションＩＤに関連するストリームの情報、受信メールのパケットのセッション管理テーブルで管理されている接続情報、及び、受信メールのパケットのプロトコル状態遷移管理テーブルで管理されているプロトコル遷移情報を削除し、構築したストリームを管理するのに使用されているメモリ領域を解放するよう構成させた。しかしながら、これに限る必要は無い。前述したセッションＩＤに関連するストリームの情報、接続情報、プロトコル遷移情報の少なくともいずれかの情報を削除するようにしてもよい。また、上記以外の情報であっても、構築したストリームのデータを管理するのに使用されている情報であれば、これを削除してメモリ領域を解放するようにしても構わない。
【０１４２】
また、上記第４の実施例では、３つのテーブルを用意し、各テーブルでそれぞれセッションＩＤに関連するストリームの情報、接続情報、プロトコル遷移情報を管理する構成をとったが、これら情報を一つのテーブルで一元管理するようにしても構わない。
【０１４３】
また、上記第４の実施例では、第１〜第３の実施例で示した構成に加え、メモリ解放機能部を更に有する構成を例にとって説明するが、これに限る必要はない。プロトコル判定部にメモリ解放機能部の機能を持たせるようにしてもよい。
【０１４４】
尚、上記第１から第４の実施例においては、説明の便宜の為、端末と本発明の検出装置とを別々のハードウェアであるとして説明したが、本発明の悪意メール検出装置の各部を端末に組み込み、端末上で悪意メール検出機能を実現させるようにしてもよい。
【０１４５】
また、上記第１から第４の実施例では、装置の各部をハードウェアで構成したが、各部の一部または全部の処理をプログラムとして情報処理装置に実行させるようにすることもできる。
【図面の簡単な説明】
【０１４６】
【図１】本実施例における悪意メール検出装置を用いた通信システムの一例を示す図
【図２】本実施例における悪意メール検出装置を用いた通信システムの他の一例を示す図
【図３】本発明における第１の実施例の構成を示すブロック図
【図４】本発明の悪意メール検出装置における処理フローを示すフローチャート
【図５】リファレンスパターンの例を示す図
【図６】メールの一例を示す図
【図７】計数テーブルの例を示す図
【図８】文字列の出現頻度の差分の算出例
【図９】本発明における第２の実施例の構成を示すブロック図
【図１０】本発明における第３の実施例の構成を示すブロック図
【図１１】本発明における第４の実施例の構成を示すブロック図
【図１２】第４の実施例におけるメモリ解放機能部の構成例を示すブロック図
【図１３】第４の実施例におけるセッション管理テーブルの例を示す図
【図１４】第４の実施例におけるストリーム管理テーブルの例を示す図
【図１５】第４の実施例における処理フローを示すフローチャート
【図１６】第４の実施例における処理フローを示すフローチャート
【符号の説明】
【０１４７】
３０  ネットワーク
４０  ネットワーク
５０  検出装置
５１  端末
５２  端末
５３  端末
６０  通信装置
６１  端末
６２  端末
６３  端末
１００  プロトコル判定部
１１０  特定部
１２０  ｎ−ｇｒａｍ処理部
１３０  判断部
１４０  検出部
１５０  記憶部
１６０  計数対象文字指示部
１７０  リファレンスパターン格納部
１８０  アクション処理部
２００  プロトコル判定部
２１０  特定部
２２０  ｎ−ｇｒａｍ処理部
２３０  判断部
２４０  検出部
２５０  記憶部
２６０  計数対象文字指示部
２７０  リファレンスパターン格納部
２８０  アクション処理部
３００  プロトコル判定部
３１０  特定部
３２０  ｎ−ｇｒａｍ処理部
３３０  判断部
３４０  検出部
３５０  記憶部
３５１  定義用テーブル
３６０  計数対象文字指示部
３７０  リファレンスパターン格納部
３８０  アクション処理部
４００  プロトコル判定部
４１０  特定部
４２０  ｎ−ｇｒａｍ処理部
４３０  判断部
４４０  検出部
４５０  記憶部
４５１  定義用テーブル
４６０  計数対象文字指示部
４７０  リファレンスパターン格納部
４８０  アクション処理部
４９０  メモリ解放機能部
４０００  セッション管理部
４００１  ストリーム再構築処理部
４００２  プロトコル状態遷移管理部
４００３  指示部
４０１０  セッション管理テーブル
４０１１  ストリーム管理テーブル
４０１２  プロトコル状態遷移管理テーブル
【図１】
2008192122.tif 000003
【図２】
2008192122.tif 000004
【図３】
2008192122.tif 000005
【図４】
2008192122.tif 000006
【図５】
2008192122.tif 000007
【図６】
2008192122.tif 000008
【図７】
2008192122.tif 000009
【図８】
2008192122.tif 000010
【図９】
2008192122.tif 000011
【図１０】
2008192122.tif 000012
【図１１】
2008192122.tif 000013
【図１２】
2008192122.tif 000014
【図１３】
2008192122.tif 000015
【図１４】
2008192122.tif 000016
【図１５】
2008192122.tif 000017
【図１６】
2008192122.tif 000018