(57)【要約】【課題】あらかじめ用途がある程度特定できる機器、システムに主として適用する、小さい処理負荷で不正アクセスや、ウィルス感染などに起因するシステムの異常状態を検出する異常検出装置を提供することを目的とする。【解決手段】システムにおける単数または複数のアプリケーションの運用状態と前記アプリケーション毎に規定されたパラメータを管理する運用アプリ・パラメータ管理手段１１０と、運用中であるアプリケーションについての前記パラメータをもとに、システムが送信または受信するパケット数異常判断の閾値を決定する閾値決定手段１１１と、システムが送信または受信するパケット数を計測して前記閾値決定手段で決定した閾値と、計測したパケット数を比較して異常を検出する異常検出処理手段１１２を保持する。【選択図】図１
2006254287.tif 000002
【特許請求の範囲】
【請求項１】
システムにおける単数または複数のアプリケーションの運用状態と前記アプリケーション毎に規定されたパラメータを管理する運用アプリ・パラメータ管理手段と、運用中であるアプリケーションについての前記パラメータをもとに、システムが送信または受信するパケット数異常判断の閾値を決定する閾値決定手段と、システムが送信または受信するパケット数を計測して前記閾値決定手段で決定した閾値と、計測したパケット数を比較して異常を検出する異常検出処理手段を保持することを特徴とする異常検出装置。
【請求項２】
前記パラメータは、前記アプリケーションが送信または受信する、あらかじめ決められた条件のパケット数に関連するパラメータであることを特徴とする請求項１記載の異常検出装置。
【請求項３】
システムで規定された単数または複数の状態の遷移を管理する状態管理手段を保持し、前記運用アプリ・パラメータ管理手段は、前記状態毎に、運用中であるアプリケーションを管理し、前記閾値決定手段は、前記状態に応じて前記異常判断の閾値を変動させることを特徴とする請求項１記載の異常検出装置。
【請求項４】
前記パラメータは、あらかじめ決められた時間あたりの接続セッション数または、切断セッション数を含むことを特徴とする請求項２記載の異常検出装置。
【請求項５】
前記パラメータは、同時設定セッション数または、同時待ち受けセッション数を含むことを特徴とする請求項２記載の異常検出装置。
【請求項６】
あらかじめ決められた条件で、前記アプリケーションを試験動作させて前記パラメータを決定する試験動作手段を保持することを特徴とした請求項１記載の異常検出装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、不正アクセスや、ウィルス感染などに起因するシステムの異常状態を検出する異常検出装置に関するものである。
【背景技術】
【０００２】
インターネットの普及に伴い、Ｗｅｂアクセスや、電子メールをはじめとした、ネットワークを利用したサービスがますます増加しつつある。しかしながら、その一方で、ネットワークを介した不正アクセスやウィルス感染により、サービスの正常運用が妨げられる危険も頻繁に生じており、その対策が必要となってきている。
【０００３】
ファイアウォールや侵入検知システム（ＩＤＳ：Ｉｎｓｔｒｕｃｔｉｏｎ  Ｄｅｔｅｃｔｉｏｎ  Ｓｙｓｔｅｍ）をネットワークに設置するなどといった対策がその代表的なものである。ＩＤＳでは、一般に、攻撃検出対象の攻撃パターンを記述した「シグネチャ」とよばれるルールに照らし合わせて攻撃を検出する方法や、ネットワーク上のパケット流の振る舞いを統計監視し、通常と異なる振る舞いを示すと攻撃とみなす方法が用いられる。
【０００４】
ネットワーク上において、不正アクセスや、ウィルス感染などの異常状態をひきおこすトラヒックを検出し、その防御を行うための先行技術としては、次のような技術が開示されている。
【０００５】
例えば、通信トラヒックが、あらかじめ管理した特定のワードリストを含む場合を異常と判断する方式が開示されている（特許文献１参照）。また、ネットワークにおける転送パケットを単数又は複数のパケット監視装置で観測し、その統計情報を収集して攻撃を検出し、攻撃防御サーバで攻撃防御するシステムが開示されている（特許文献２参照）。また、ネットワークに対するユーザのイベントをログデータとして収集し、収集されたログデータからユーザ毎に通常のネットワーク使用状況を表すプロファイルを作成し、新たに収集したログデータとプロファイルを照合することによって、不正侵入の恐れを検知する方法が開示されている（特許文献３参照）。
【特許文献１】特開２００２−１８９６４３号公報
【特許文献２】特開２００４−３２８３０７号公報
【特許文献３】特開２００２−１３５２４８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従来の技術における、特許文献１による方法では、様々な異常を検出するためには、異常と判断されるワードリストの種類を多くする必要があり、異常判断の処理負荷が増大するため、高性能なハードウェアが必須となる。また、ワードリストに含まれない異常については検出できない。特許文献２では、異常判断の方法として、トラヒックの観測値の統計情報による方式が開示されているが、具体的な攻撃検出の方法は特定していない。
【０００７】
特許文献３では、異常判断の方法として、通常観測されるトラヒックから外れるものを異常と判断しているが、システムの運用状況によってトラヒックそのものが変動する場合には、異常の判断が容易ではない。
【０００８】
本発明では、ネット家電など、あらかじめ用途がある程度特定できる機器、システムに主として適用する、小さい処理負荷で異常状態を検出する異常検出装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
前記従来の課題を解決するために、本発明の異常検出装置は、システムにおける単数または複数のアプリケーションの運用状態と前記アプリケーション毎に規定されたパラメータを管理する運用アプリ・パラメータ管理手段と、運用中であるアプリケーションについての前記パラメータをもとに、システムが送信または受信するパケット数異常判断の閾値を決定する閾値決定手段と、システムが送信または受信するパケット数を計測して前記閾値決定手段で決定した閾値と、計測したパケット数を比較して異常を検出する異常検出処理手段を保持する。
【発明の効果】
【００１０】
本発明の異常検出装置によれば、システムにおける単数または複数のアプリケーションの運用状態と前記アプリケーション毎に規定されたパラメータを管理する運用アプリ・パラメータ管理手段と、運用中であるアプリケーションについての前記パラメータをもとに、システムが送信または受信するパケット数異常判断の閾値を決定する閾値決定手段と、システムが送信または受信するパケット数を計測して前記閾値決定手段で決定した閾値と、計測したパケット数を比較して異常を検出する異常検出処理手段を保持することにより、システムの正常動作範囲を管理し、これを異常判断の閾値に反映させることが可能となる。
【００１１】
たとえば、ネット家電など、あらかじめ用途がある程度特定できる機器やシステムにおいて、小さい処理負荷で異常状態を検出する異常検出装置を提供することが可能となる。また、アプリケーションの運用状態に応じて閾値を設定することができ、異常トラヒックの検出効率を運用状況に合わせて最適化することが可能となる。
【発明を実施するための最良の形態】
【００１２】
以下本発明の実施の形態について、図面を参照しながら説明する。
【００１３】
（実施の形態１）
図１は、本発明の実施の形態１における異常検出装置を有するシステムの構成例である。
【００１４】
１０１、１０２、１０３はシステムにおいて運用されているアプリケーションである。アプリケーション１０１〜アプリケーション１０３は通信処理手段１０４を介し、通信ネットワーク１０８に接続されており、相手先アプリ１０５、１０６、１０７と通信を行う。１０９は、本発明の実施の形態１における異常検出装置である。異常検出装置１０９は、アプリケーションの運用状態と、アプリケーション１０１〜１０３それぞれに規定されているパラメータを管理する運用アプリ・パラメータ管理手段１１０、異常検出のための閾値を決定する閾値決定手段１１１、通信処理手段を介して送受信されるパケットについての異常を検出する異常検出手段１１２で構成されている。
【００１５】
図２は、運用アプリ・パラメータ管理手段１１０で管理しているアプリケーションの運用状態を管理する管理データの例である。システムに存在するアプリケーションとしては、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇがあり、そのうちＡ〜Ｅが運用されている状態にあることを示している。Ｆ、Ｇは運用されていないアプリケーションである。図３は、運用アプリ・パラメータ管理手段１１０で管理しているパラメータの例である。アプリケーションＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇそれぞれについて、パラメータａ、ｂ、ｃ、ｄ、ｅ、ｆ、ｇを管理している。閾値決定手段１１１では、運用アプリ・パラメータ管理手段１１０の情報をもとに、運用されているアプリケーションを把握する。そして、運用状態のアプリケーションＡ〜Ｅについてのパラメータを運用アプリ・パラメータ管理手段１１０より得る。この場合、パラメータａ、ｂ、ｃ、ｄ、ｅがこれに該当する。そして、あらかじめ決められた計算式にしたがって、閾値を決定する（式１）。最も簡単な例としては、パラメータａ、ｂ、ｃ、ｄ、ｅは、あらかじめ決められた時間あたりの送信または受信パケット数の最大値であり、（式２）の様に該当パラメータを加算して閾値を求める場合が考えられる。
【００１６】
閾値＝ｆ（ａ、ｂ、ｃ、ｄ、ｅ）・・・  式１
閾値＝ａ＋ｂ＋ｃ＋ｄ＋ｅ・・・  式２
以上の様にして決定した閾値を用いて、異常検出処理手段１１２では、通信処理手段を介して送受信されるパケットについての異常を検出する。図４は、異常検出処理手段１１２で行う処理の内容を示すフロー図である。異常検出処理手段１１２では、あらかじめ決められた時間に送信または受信されるパケット数を計測する（ステップＳ４０１）。そして、計測したパケット数を閾値と比較して異常判断を行う（ステップＳ４０２）。たとえば、ウィルス感染や、不正アクセスなどにより、図１の不正アプリ１１３に示したような不正アプリが動作し、通信ネットワーク１０８に送出する通信トラヒックが増加した場合や、逆に、攻撃者１１４が通信ネットワーク１０８を介して通信処理手段に対してパケットを送信してきた場合などは、パケット数の計測値が閾値を上回ることとなり、異常と判断される。
【００１７】
次に、パラメータと閾値のより具体的な例を用いて、閾値の決定方法を説明する。図５は、運用アプリ・パラメータ管理手段１１０で管理しているパラメータのより具体的な例である。それぞれのアプリケーションについて、自アプリから他へ送信されるパケット数または接続されるセッション数、逆に、他から自アプリへ送信されるパケット数または接続されるセッション数について、あらかじめ決められた「時間」あたりの「数」の最大値をパラメータとして、種類毎に管理する。この「時間」と「数」は、それぞれのアプリケーションの仕様として規定されているものである。たとえば、アプリケーションＡでは、自アプリから他に接続するセッション数の最大値は１０秒あたり５０が最大となっていることを管理する。また、ＴＣＰデータパケットについては、１０秒あたり最大２０パケット送信されることを管理する。図５のように管理されたパラメータを用いて、閾値決定手段１１１は閾値を決定する。図６は、閾値決定手段１１１が決定した閾値のより具体的な例である。たとえば、自アプリから他方向のＴＣＰ  ＳＹＮ  ｎｏｔ  ＡＣＫパケットの最大値は、アプリＡの自アプリから他への接続セッション数１０と、アプリＢの接続セッション数３０と、アプリＣの接続セッション数２０を加算した値６０に、あらかじめ決められた再送見込み分１０％を考慮し、１秒あたり６６と定める。他の項目についても、同様にして、閾値を算出し、パケットの種類毎に閾値を設ける。
【００１８】
（実施の形態２）
図７は、本発明の実施の形態２における異常検出装置を有するシステムの構成例である。
【００１９】
７０１、７０２、７０３はシステムにおいて運用されているアプリケーションである。アプリケーション７０１〜アプリケーション７０３は通信処理手段７０４を介し、通信ネットワーク７０８に接続されており、相手先アプリ７０５、７０６、７０７と通信を行う。７０９は、本発明の実施の形態１における異常検出装置である。異常検出装置７０９は、アプリケーションの運用状態と、アプリケーション７０１〜７０３それぞれについて規定されているパラメータを管理する運用アプリ・パラメータ管理手段７１０、たとえば、起動中、運用中、メンテナンス中といったシステム全体の状態を管理する状態管理手段７１１、異常検出のための閾値を決定する閾値決定手段７１２、通信処理手段を介して送受信されるパケットについての異常を検出する異常検出処理手段７１３、パラメータを決定するためのアプリケーションの試験動作を実行する試験動作手段７１４で構成されている。
【００２０】
図８は、運用アプリ・パラメータ管理手段７１０で管理している管理データの例である。システムに存在するアプリケーションとしては、Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆがある。状態毎に運用されるアプリケーションは異なり、パラメータ値が０以外のアプリケーションが運用されている。状態１では、アプリケーションＡ、Ｂ、Ｃ、Ｄ、Ｅが運用されており、それぞれのパラメータはａ、ｂ、ｃ、ｄ、ｅである。また、状態２ではアプリケーションＡ、Ｆが運用されており、それぞれのパラメータはａ’、ｆ’である。状態１、状態２は、システムであらかじめ決められているものであり、たとえば状態１として運用中状態、状態２として電源投入後の起動中状態といった状態である。
【００２１】
閾値決定手段７１２では、状態管理手段７１１で管理しているシステムの状態情報と、運用アプリ・パラメータ管理手段７１０の情報をもとに、運用されているアプリケーションを把握する。そして、運用状態のアプリケーションについてのパラメータを運用アプリ・パラメータ管理手段７１０より得る。システムの状態が状態１の場合、パラメータａ、ｂ、ｃ、ｄ、ｅがこれに該当する。そして、あらかじめ決められた計算式にしたがって、閾値を決定する（式１）。最も簡単な例としては、パラメータａ、ｂ、ｃ、ｄ、ｅは、あらかじめ決められた時間あたりの送信または受信パケット数の最大値であり、（式２）の様に該当パラメータを加算して閾値を求める場合が考えられる。
【００２２】
状態２の場合には、パラメータａ’、ｆ’がこれに該当する。
【００２３】
状態２のときの閾値は、（式３）の様になる。
【００２４】
閾値＝ａ’＋ｆ’・・・  式３
電源投入時の、システムの状態が状態２のときには、閾値は（式３）で求めた値となっている。システムの状態が状態２から状態１へ遷移すると、状態管理手段７１１は、閾値決定手段７１２に状態が遷移したことを通知する。そして、閾値決定手段７１２は、閾値を（式２）で求めた値に変更する。
【００２５】
以上の様にして決定した閾値を用いて、異常検出処理手段７１３では、通信処理手段を介して送受信されるパケットについての異常を検出する。異常検出動作は、図１の異常検出処理手段１１３の動作と同様である。
【００２６】
次に、パラメータと閾値のより具体的な例を用いて、閾値の決定方法を説明する。運用アプリ・パラメータ管理手段７１０では、先の実施の形態１で説明した図５のようなパラメータを状態１のパラメータとして管理している。また、状態２のパラメータについても別途管理している。図９は、運用アプリ・パラメータ管理手段７１０で管理している状態２のパラメータのより具体的な例である。それぞれのアプリケーションについて、自アプリから他へ送信されるパケット数または接続されるセッション数、逆に、他から自アプリへ送信されるパケット数または接続されるセッション数について、あらかじめ決められた「時間」あたりの「数」の最大値を種類毎に管理する。この「時間」と「数」は、試験動作手段７１４により、あらかじめ決められた条件でアプリケーションを動作させ、決定する。試験動作の条件は、アプリケーションが送受信するパケット数が最も多くなる条件が選択される。試験動作手段７１４による動作によって得たパラメータ値、たとえば、アプリケーションＡでは、自アプリから他に接続するセッション数の最大値は１０秒あたり５が最大となっていることを管理する。また、ＴＣＰデータパケットについては、１０秒あたり最大１０パケット送信されることを管理する。
【００２７】
図９のように管理されたパラメータを用いて、閾値決定手段７１２は、状態２での閾値を決定する。図１０は、閾値決定手段７１２が決定した閾値のより具体的な例である。たとえば、自アプリから他方向のＴＣＰ  ＳＹＮ  ｎｏｔ  ＡＣＫパケットの最大値は、アプリＡの自アプリから他への接続セッション数５と、アプリＦの接続セッション数３を加算した値８に、あらかじめ決められた再送見込み分１０％を考慮し、１秒あたり９と定める。他の項目についても、同様にして、閾値を算出し、パケットの種類毎に閾値を設ける。
【００２８】
状態１の場合にも、先に説明した図５のようなパラメータを用いて、状態１での閾値を算出する。
【００２９】
以上、本発明の異常検出装置について図面を用いて説明したが、パラメータの管理項目は一例であり、これに限定されない。たとえば、プロトコル番号や、宛先、送信元といった種別毎のパラメータをもつという方法もある。このときには、指定された種別にたいして、異常判断の閾値が設けられる。１つのアプリケーションが複数のプロセスを構成する場合には、プロセスの個数の関数として、パラメータが定義づけられる場合もある。実施例では、送信パケット、受信パケット両方について異常検出する例をしめしたが、どちらか一方でも構わない。
【００３０】
また、再送マージンや、パラメータから閾値の算出式についても、これに限定されない。
【００３１】
実施の形態２では、システムの状態として定義されている状態１、状態２それぞれで運用されているアプリケーションの種類があらかじめ決まっているとしたが、同じシステムの状態でも、運用アプリの種類が変動する場合もある。この場合には、各アプリの運用状態をシステムの状態毎に管理し、運用状態に応じて閾値を変動させる。
【００３２】
以上、本発明の異常検出装置によれば、運用アプリ・パラメータ管理手段１１０、７１０と、運用中であるアプリケーションについてのパラメータをもとに、システムが送信または受信するパケット数異常判断の閾値を決定する閾値決定手段１１１、７１０を保持することにより、システムの正常動作範囲を管理し、これを異常判断の閾値に反映させることが可能となる。
【００３３】
たとえば、ネット家電など、あらかじめ用途がある程度特定できる機器やシステムにおいて、小さい処理負荷で異常状態を検出する異常検出装置を提供することが可能となる。また、アプリケーションの運用状態に応じて閾値を設定することができ、異常トラヒックの検出効率を運用状況に合わせて最適化することが可能となる。
【産業上の利用可能性】
【００３４】
本発明にかかる異常検出装置は、アプリケーションの運用状態に応じて異常判断の閾値を設定することができ、あらかじめ用途がある程度特定できる機器やシステムにおいて、小さい処理負荷で異常状態を検出する異常検出装置を提供することが可能となる。
【図面の簡単な説明】
【００３５】
【図１】本発明の実施の形態１における異常検出装置を有するシステムの構成例を示す図
【図２】本発明の実施の形態１における運用アプリ・パラメータ管理手段１１０で管理している運用アプリの管理データの例を示す図
【図３】本発明の実施の形態１における運用アプリ・パラメータ管理手段１１０で管理しているパラメータの例を示す図
【図４】本発明の実施の形態における異常処理手段１１２で行う処理の内容を示すフローチャート
【図５】本発明の実施の形態１における運用アプリ・パラメータ管理手段１１０で管理しているパラメータのより具体的な例、本発明の実施の形態２における運用アプリ・パラメータ管理手段７１０が管理している、状態１の管理データのより具体的な例を示す図
【図６】本発明の実施の形態１における閾値決定手段１１１で決定される閾値のより具体的な例、本発明の実施の形態１における閾値決定手段７１２で決定される状態１の閾値のより具体的な例を示す図
【図７】本発明の実施の形態２における異常検出装置を有するシステムの構成例を示す図
【図８】本発明の実施の形態２における運用アプリ・パラメータ管理手段７１０が管理している管理データの例を示す図
【図９】本発明の実施の形態２における運用アプリ・パラメータ管理手段７１０が管理している、状態２の管理データのより具体的な例を示す図
【図１０】本発明の実施の形態１における閾値決定手段７１２で決定される状態２の閾値のより具体的な例を示す図
【符号の説明】
【００３６】
１０１〜１０３    アプリケーション
１０４    通信処理手段
１０５〜１０７    相手先アプリ
１０８    通信ネットワーク
１０９    異常検出装置
１１０    運用アプリ・パラメータ管理手段
１１１    閾値決定手段
１１２    異常検出処理手段
１１３    不正アプリ
１１４    攻撃者
７０１〜７０３    アプリケーション
７０４    通信処理手段
７０５〜７０７    相手先アプリ
７０８    通信ネットワーク
７０９    異常検出装置
７１０    運用アプリ・パラメータ管理手段
７１１    状態管理手段
７１２    閾値決定手段
７１３    異常検出処理手段
７１４    試験動作手段
【図１】
2006254287.tif 000003
【図２】
2006254287.tif 000004
【図３】
2006254287.tif 000005
【図４】
2006254287.tif 000006
【図５】
2006254287.tif 000007
【図６】
2006254287.tif 000008
【図７】
2006254287.tif 000009
【図８】
2006254287.tif 000010
【図９】
2006254287.tif 000011
【図１０】
2006254287.tif 000012