JP6173613B2 - Ｈｔｔｐトラフィックを搬送するｔｃｐ接続を分類する方法、デバイス、コンピュータプログラム及び情報記憶手段 - Google Patents

Description

本発明は、一般的には、ＨＴＴＰトラフィックを搬送するＴＣＰ接続を信頼ＴＣＰ接続または非信頼ＴＣＰ接続として分類することに関する。

ＨＴＴＰ（ＩＥＴＦ（「インターネットエンジニアリングタスクフォース」）によって公開された標準文書ＲＦＣ２６１６によって定義されるように、「ハイパーテキスト転送プロトコル」）プロトコルは、ＴＣＰ（標準文書ＲＦＣ７９３によって定義されるように、「伝送制御プロトコル」）セグメントを介して運ばれる。
ＨＴＴＰプロトコルは、セッションレベルの部分として見なすことができる。
今日、ＨＴＴＰプロトコルは、ボリュームに関してのみならず、ＨＴＴＰプロトコルに頼るサービスの多様性に関しても、最も使用されるセッションプロトコルになっている。
実際に、ますます多くのアプリケーションがウェブブラウザ環境内で実行され、またはウェブブラウザ機能を実施し、それらの通信はＨＴＴＰプロトコルに基づく。
ＨＴＴＰプロトコルの１つの利点は、簡素性である。その理由は、ＨＴＴＰプロトコルが少数の要求メソッドをサポートし、基本的に、アプリケーションは主に、要求メソッドのうちの２つまたは３つ（例えば、ＧＥＴ要求およびＰＯＳＴ要求）を使用する。
多くのアプリケーションは、ＨＴＴＰプロトコルをセッションプロトコルとして使用する。ＨＴＴＰプロトコルは、ウェブブラウザによって使用されるのみならず、ファイルをダウンロードする好ましい方法として多くのソフトウェアアプリケーションによっても使用される。したがって、多くのソフトウェア更新手順は、ＨＴＴＰプロトコルに頼る。
インスタントメッセージングまたはクラウドサービスも、ＨＴＴＰプロトコルをセッションレイヤとして使用し得る。

ＨＴＴＰプロトコルの実施は、かなり柔軟であり、幾つかの大きなセマンティックおよびシンタックスバリエーションをサポートし得る。実際に、ＨＴＴＰプロトコルは、テキストベースのプロトコルであり、大小文字を区別しない。標準文書ＲＦＣ２６１６は、予め定義される値を有する幾つかの標準化ＨＴＴＰヘッダを定義するが、ＨＴＴＰクライアントアプリケーションおよびＨＴＴＰサーバアプリケーションによって使用されるＨＴＴＰメッセージにおいて必須とされるのは、それらのうちの極めて少なくない数のものである。
幾つかの追加のヘッダが、プロキシ、ファイル交換等の幾つかの特定の機能のために、他の標準文書によって定義された。加えて、幾つかのプロプライエタリＨＴＴＰヘッダも、任意のアプリケーションによって定義することができ、それらの使用は制限されない。

幾つかの標準化ＨＴＴＰヘッダフィールドの値は、対応するＨＴＴＰメッセージを生成するアプリケーションまたは前記アプリケーションの実行に使用される端末の領域設定に依存し得る。
一例によれば、ＨＴＴＰプロトコルは、ＨＴＴＰメッセージを生成するアプリケーションを識別することが意図される「ユーザエージェント」ヘッダを定義する。ユーザエージェントヘッダは通常、ＨＴＴＰクライアントアプリケーションについてのソフトウェアバージョン情報、およびＨＴＴＰクライアントアプリケーションが実行されるオペレーティングシステムについてのソフトウェアバージョン情報を含む。
別の例によれば、ＨＴＴＰプロトコルは「許容言語」ヘッダを定義する。この「許容言語」ヘッダは、そのような「許容言語」ヘッダを含む要求への応答を形成するために好ましい１組の自然言語を定義することが意図される。

したがって、ＨＴＴＰプロトコルの実施は同じＨＴＴＰ ＡＰＩ（「アプリケーションプログラミングインターフェース」）に頼るが、異なるＨＴＴＰヘッダが異なる順序で存在し得、異なるシンタックスがヘッダ値のエンコードに使用されるように見える。

マルウェア、トロイ、またはリモート管理ツール（ＲＡＴ）等の悪意のあるアプリケーションも多くの場合、
悪意のあるアプリケーションを伝搬させた誰かの制御下で、感染デバイスと呼ばれる、悪意のあるアプリケーションを実行するデバイスと、コマンドおよび制御（Ｃ＆Ｃ）サーバと呼ばれるサーバとの通信をセットアップする搬送プロトコルとして、
ＨＴＴＰプロトコルを使用する。

悪意のあるＨＴＴＰデータフローを検出し分類する方法が提案されている。しかし、前記方法は通常、ＵＲＬ（「ユニフォームリソースロケータ」）およびＩＰ（ＲＦＣ７９１によって定義されるように、「インターネットプロトコル」）宛先アドレス分析に頼り、潜在的な脅威および漏出を検出する。幾つかのＵＲＬブラックリストが通常、疑いのある通信を分離するために使用され、幾つかのＵＲＬホワイトリストが通常、信頼される通信を許可するために使用される。同様の手法が、ＩＰアドレスブラックリストおよびホワイトリストとも使用される。

上述した方法の主な問題は、ＩＰアドレスおよびＵＲＬに頼ることが、信頼できないことがあることである。実際に、非信頼マシンまたはＵＲＬが、ホワイトリストおよびブラックリストに短期で反映されずに現れ得る。ホワイトリストおよびブラックリストの管理は通常、中央手法に頼り、ホワイトリストおよびブラックリストは、悪意のあるソフトウェア構成においてサーバとして機能して新しいマシンまたは新しいＵＲＬによってポイントされるサービスが発見されると、人間の管理者によって更新される。

上述した方法に伴う別の主な問題は、通常、中央でオフラインにて埋められるデータベースに頼ることである。これは、オペレータがホワイトリストまたはブラックリストに入れる新しいＩＰアドレスまたは新しいＵＲＬが発見した場合に、データベースが更新されることを意味する。したがって、これはユーザの環境に適合しないことがある。したがって、そのようなデータベースをより簡単かつより効率的に埋めることができる解決策を提供することが望ましい。

技術的現況の上記欠点を解消することが望ましい。

特に、ＩＰアドレスおよびＵＲＬよりも信頼性の高い情報に基づいて、ＨＴＴＰトラフィックを搬送しているＴＣＰ接続を信頼ＴＣＰ接続または非信頼ＴＣＰ接続として分類することができる解決策を提供することが望ましい。

したがって、従来技術の解決策と比較して改善された分類性能をもたらす解決策を提供することが望ましい。

特に、新しい悪意のあるソフトウェアの伝搬に反応する解決策を提供することが望ましい。

実施が容易であり、費用効率的な解決策を提供することが更に望ましい。

そのために、本発明は、分析デバイスによって実行される、信頼ＴＣＰ接続または非信頼ＴＣＰ接続としてＨＴＴＰトラフィックを搬送するＴＣＰ接続を分類する方法に関する。本方法は、ＴＣＰ接続によって搬送されるＨＴＴＰトラフィック内のＨＴＴＰセッションのＨＴＴＰ要求メッセージを検出することと、検出されたＨＴＴＰ要求メッセージのヘッダから、ＨＴＴＰセッションのシグネチャを構築するための情報を取得することと、ＨＴＴＰセッションのシグネチャを、分析デバイスによって事前にシグネチャデータベースに記憶されたシグネチャと比較することと、ＨＴＴＰセッションのシグネチャが、シグネチャデータベースに分析デバイスによって事前に記憶され、信頼ＨＴＴＰクライアントアプリケーションを表すシグネチャに一致する場合、ＴＣＰ接続を信頼接続として分類することと、ＨＴＴＰセッションのシグネチャが、シグネチャデータベースに分析デバイスによって事前に記憶されたいずれのシグネチャにも一致しない場合、認証データを提供するようにユーザに要求する認証手順を実行することと、有効な認証データがユーザによって提供される場合、ＨＴＴＰセッションのシグネチャをシグネチャデータベースに追加し、ＨＴＴＰセッションのシグネチャは、シグネチャデータベース内で信頼ＨＴＴＰクライアントアプリケーションを表し、ＴＣＰ接続を信頼接続として分類することと、有効な認証データが前記ユーザによって提供されない場合、ＴＣＰ接続を非信頼接続として分類することとを含む。

したがって、シグネチャデータベースの内容がユーザの環境に適合するように、シグネチャデータベースを単純かつ効率的に埋めることができる。

特定の実施形態によれば、ＴＣＰ接続が、認証手順に続き非信頼接続として分類される場合、本方法は、ＨＴＴＰセッションのシグネチャをシグネチャデータベースに追加することであって、ＨＴＴＰセッションのシグネチャは、シグネチャデータベース内で、非信頼ＨＴＴＰクライアントアプリケーションを表す、追加することを更に含む。

したがって、シグネチャデータベースは、信頼および非信頼ＨＴＴＰクライアントアプリケーションの両方に関連する情報を含む。

特定の実施形態によれば、シグネチャデータベースに記憶される各シグネチャには、前記シグネチャが信頼ＴＣＰ接続に対応するか、または非信頼ＴＣＰ接続に対応するかを表す第１の安全性インジケータが関連付けられる。

したがって、記憶されたシグネチャがＴＣＰ接続に対応するか、または非信頼ＴＣＰ接続に対応するかの判断は

特定の実施形態によれば、ＨＴＴＰセッションのシグネチャは、検出されたＨＴＴＰ要求メッセージに存在するＨＴＴＰ必須ヘッダを表す情報と、検出されたＨＴＴＰ要求メッセージに存在するＨＴＴＰ任意選択的ヘッダを表す情報と、ＨＴＴＰ必須ヘッダが検出されたＨＴＴＰ要求メッセージに現れるシーケンスを表す情報と、検出されたＨＴＴＰ要求メッセージに存在するＨＴＴＰ必須ヘッダの予め定義されるフィールドに含まれる値を表す情報とを含む。

したがって、ＨＴＴＰヘッダの存在、ＨＴＴＰヘッダシーケンス、およびＨＴＴＰ必須ヘッダの予め定義されるフィールドに含まれる値のに頼ることにより、ＴＣＰ接続の分類の信頼性はより高くなる。

特定の実施形態によれば、シグネチャデータベースに記憶されるシグネチャには、少なくとも１つのＩＰアドレスのセットが関連付けられ、前記方法は、ＨＴＴＰセッションのシグネチャをシグネチャデータベースに追加する際、ＨＴＴＰセッションのシグネチャに、ＨＴＴＰ要求メッセージを発したＩＰソースアドレスを関連付けることと、ＨＴＴＰセッションのシグネチャをシグネチャデータベースに事前に記憶されたシグネチャと比較する際、ＩＰソースアドレスに、シグネチャデータベースに事前に記憶された任意のシグネチャが関連付けられているか否かをチェックすることと、シグネチャデータベース内のシグネチャにＩＰソースアドレスが関連付けられていない場合、ＨＴＴＰセッションのシグネチャがシグネチャデータベース内のいずれのシグネチャにも一致しないと見なすこととを含む。

したがって、ＨＴＴＰセッションのシグネチャにＩＰソースアドレスを関連付けることにより、ＴＣＰ接続の分類はより正確であり、ユーザの環境に動的に適合する。さらに、どのＨＴＴＰクライアントアプリケーションがどのデバイスで実行されるかの細かい全体像を有することができ、悪意のあるＨＴＴＰクライアントアプリケーションによるなりすましのリスクを制限することができる。

特定の実施形態によれば、認証手順は、検出されたＨＴＴＰ要求メッセージを発したデバイスに応答を送信することであって、前記応答は、検出されたＨＴＴＰ要求メッセージを発したデバイスを別のＵＲＬにリダイレクトする、送信することと、検出されたＨＴＴＰ要求メッセージを発したデバイスから、前記別のＵＲＬを参照する別のＨＴＴＰ要求メッセージを受信することと、前記別のＨＴＴＰ要求メッセージに応答して、ユーザが認証情報を入力することができるウェブページを送信することと、有効な認証情報が受信される場合、ＴＣＰ接続を信頼と見なし、その他の場合、ＴＣＰ接続を非信頼と見なすこととを含む。

したがって、認証は、人間によってのみ実行されることが予期され、これは、ＴＣＰ接続が悪意のあるＨＴＴＰクライアントアプリケーションに関わるのに反して、前記ＴＣＰ接続が信頼として宣言することを回避するはずである。

特定の実施形態によれば、ウェブページは、認証情報としてログインおよびパスワードをユーザが入力できるようにするよう構成され、分析デバイスは、入力されたログインおよびパスワードを事前に記憶されたログインおよびパスワードと比較するか、またはウェブページは、ＣＡＰＴＣＨＡ（「Completely Automated Public Turing test to tell Computers and Humans Apart: コンピュータと人間を区別する完全に自動化された公開チューリングテスト」）画像を表示し、ユーザが文字列を入力できるようにするよう構成され、分析デバイスは、入力された文字列を表示されたＣＡＰＴＣＨＡ画像に対応する予め定義される文字と比較する。

したがって、認証セキュリティが強化される。

特定の実施形態によれば、ウェブページは、検出されたＨＴＴＰ要求メッセージに適合するものとして分析デバイスによって決定されるプロファイルのセットの中からプロファイルをユーザが選択できるようにするよう更に構成され、各プロファイルは、シグネチャに適合する各ＨＴＴＰ要求メッセージに存在すると予期されるＨＴＴＰ必須ヘッダのリストと、シグネチャに適合する各ＨＴＴＰ要求メッセージに存在すると予期されるＨＴＴＰ任意選択的ヘッダのリストと、シグネチャに適合する各ＨＴＴＰ要求メッセージに存在する特定の値を有するＨＴＴＰ必須ヘッダのリストと、ＨＴＴＰ必須ヘッダが検出されたＨＴＴＰ要求メッセージに現れるシーケンスを表す情報とを含む。

したがって、プロファイルに頼ることは、シグネチャデータベースに追加されるシグネチャの定義を容易にする。

特定の実施形態によれば、有効な認証情報が受信される場合、分析デバイスは、選択されたプロファイルおよび検出されたＨＴＴＰ要求メッセージのヘッダからＨＴＴＰセッションのシグネチャを特定する。

したがって、シグネチャの定義は更に容易になる。

特定の実施形態によれば、方法は、検出されたＨＴＴＰ要求メッセージに関連付けられたＩＰ宛先アドレスを表す情報を取得することと、シグネチャに基づいてＴＣＰ接続を分類しようとする前に、ＩＰ宛先アドレスに基づいてＴＣＰ接続を信頼ＴＣＰ接続または非信頼ＴＣＰ接続として分類しようとすることとを含む。

したがって、シグネチャベースの分類手法は、より簡単なＩＰベースの分類手法の試みが成功しなかった場合に実施される。

特定の実施形態によれば、方法は、ＩＰ宛先アドレスをＩＰアドレスデータベースに事前に記憶されたＩＰアドレスと比較することを含み、ＩＰアドレスデータベースに記憶される各ＩＰアドレスには、前記ＩＰアドレスが信頼デバイスに対応するか、または非信頼デバイスに対応するかを表す第２の安全性インジケータが関連付けられ、各ＴＣＰ接続は、信頼宛先デバイスが信頼として見なされることを暗に示し、各ＴＣＰ接続は、非信頼宛先デバイスが非信頼として見なされることを暗に示す。

したがって、ＩＰアドレスベースのより簡単な分類手法は、実施が簡単である。さらに、ソフトウェア更新ＨＴＴＰクライアントアプリケーション等の１つ又は少数のドメインにアクセスする正当なＨＴＴＰクライアントアプリケーションをより容易に分類することができる。

特定の実施形態によれば、ＩＰアドレスデータベースを埋めるために、方法は、ＵＤＰ（「User Datagram Protocol: ユーザデータグラムプロトコル」）データグラムを受信することと、受信したＵＤＰデータグラム内のＤＮＳ（「Domain Name System: ドメイン名システム」）サーバ応答を検出することと、検出されたＤＮＳサーバ応答から、ＩＰアドレスとドメイン名情報との一致の情報を取得することと、前記ドメイン名情報がドメイン名データベースに存在するか否かをチェックすることであって、前記ドメイン名データベースは、前記ドメイン名が信頼であるか、または非信頼であるかを表す第３の安全性インジケータが関連付けられたドメイン名を含む、チェックすることと、前記ドメイン名情報がドメイン名データベースに存在する場合、ＩＰアドレスデータベースに、第３の安全性インジケータに関連付けて、前記ドメイン名情報に一致するＩＰアドレスを追加することとを含む。

したがって、ＩＰアドレスデータベースは自動的に埋めることができる。

特定の実施形態によれば、方法は、検出されたＨＴＴＰ要求メッセージのヘッダから、ＨＴＴＰ要求メッセージが参照するＵＲＬを表す情報を取得することと、シグネチャに基づいてＴＣＰ接続を分類しようとする前に、ＵＲＬに基づいてＴＣＰ接続を信頼ＴＣＰ接続または非信頼ＴＣＰ接続として分類しようとすることとを含む。

したがって、シグネチャベースの分類手法は、より簡単なＵＲＬベースの分類手法の試みが成功しない場合に実施される。さらに、ソフトウェア更新ＨＴＴＰクライアントアプリケーション等の１つ又は少数のドメインにアクセスする正当なＨＴＴＰクライアントアプリケーションをより容易に分類することができる。

特定の実施形態によれば、方法は、ＵＲＬをＵＲＬデータベースに事前に記憶されたＵＲＬと比較することを含み、ＵＲＬデータベースに記憶された各ＵＲＬには、前記ＵＲＬが信頼デバイスに対応するか、または非信頼デバイスに対応するかを表す第４の安全性インジケータが関連付けられ、信頼ＵＲＬを参照するＨＴＴＰ要求メッセージを運ぶ各ＴＣＰ接続は、信頼として見なされ、各ＴＣＰ接続は、非信頼ＵＲＬが非信頼として見なされることを暗に示す。

したがって、ＵＲＬベースのより簡単な分類手法は、実施が簡単である。

別の態様によれば、本発明は、信頼ＴＣＰ接続または非信頼ＴＣＰ接続としてＨＴＴＰトラフィックを搬送するＴＣＰ接続を分類するデバイスにも関する。前記デバイスは、ＴＣＰ接続によって搬送されるＨＴＴＰトラフィック内のＨＴＴＰセッションのＨＴＴＰ要求メッセージを検出する手段と、検出されたＨＴＴＰ要求メッセージのヘッダから、ＨＴＴＰセッションのシグネチャを構築するための情報を取得する手段と、ＨＴＴＰセッションのシグネチャを、分析デバイスによって事前にシグネチャデータベースに記憶されたシグネチャと比較する手段と、ＨＴＴＰセッションのシグネチャが、シグネチャデータベースに分析デバイスによって事前に記憶され、信頼ＨＴＴＰクライアントアプリケーションを表すシグネチャに一致する場合、ＴＣＰ接続を信頼接続として分類する手段と、ＨＴＴＰセッションのシグネチャが、シグネチャデータベースに分析デバイスによって事前に記憶されたいずれのシグネチャにも一致しない場合、認証手順を実行する手段であって、認証手順は、認証データを提供するようにユーザに要求する、実行する手段と、有効な認証データがユーザによって提供される場合、ＨＴＴＰセッションのシグネチャをシグネチャデータベースに追加し、ＨＴＴＰセッションのシグネチャは、シグネチャデータベース内で信頼ＨＴＴＰクライアントアプリケーションを表し、ＴＣＰ接続を信頼接続として分類する手段と、有効な認証データがユーザによって提供されない場合、ＴＣＰ接続を非信頼接続として分類する手段とを備える。

本発明は、通信ネットワークからダウンロードすることができ、かつ／またはコンピュータによって読み出し、プロセッサによって実行することができる媒体に記憶することができるコンピュータプログラムにも関する。このコンピュータプログラムは、前記プログラムがプロセッサによって実行されると、実施形態の任意の１つでの上述した方法を実施する命令を含む。本発明は、そのようなコンピュータプログラムを記憶した情報記憶媒体にも関する。

デバイスおよびコンピュータプログラムに関連する特徴および利点は、対応する上述した方法に関して既に述べたものと同一であるため、前記特徴および利点についてはここで繰り返さない。

本発明の特徴は、実施形態例の以下の説明を読むことからより明確に浮かび上がり、前記説明は、添付図面を参照して行われる。

本発明を実施し得る通信システムを概略的に表す。 通信システムの分析デバイスのアーキテクチャを概略的に表す。 分析デバイスのモジュール式構成を概略的に表す。 シグネチャ情報をシグネチャデータベースに記憶する構造の例を概略的に表す。 ＴＣＰ接続を分類する、分析デバイスによって実行されるアルゴリズムを概略的に表す。 ＴＣＰ接続のシグネチャをチェックし、必要な場合、シグネチャデータベースを更新する、分析デバイスによって実行されるアルゴリズムを概略的に表す。 新しいエントリをＩＰアドレスデータベースに追加する、分析デバイスによって実行されるアルゴリズムを概略的に表す。

ユーザの制御下にないアプリケーション（例えば、マルウェア、ルートキット）を検出する文脈の中で、ＨＴＴＰトラフィックを搬送するＴＣＰ接続を信頼または非信頼として分類するに当たり性能を改善するとともに、ユーザの環境に従ってＴＣＰ接続の分類を動的に適合させるために、ＨＴＴＰトラフィック内のＨＴＴＰ要求メッセージに含まれる情報からＨＴＴＰセッションシグネチャを特定し、特定されたシグネチャが、シグネチャデータベースに事前に記憶されたシグネチャに一致するか否かを更に判断することが提案される。
シグネチャがシグネチャデータベースに記憶されたシグネチャに一致する場合、記憶されたシグネチャに関連付けられた安全性インジケータは、ＴＣＰ接続が信頼ＴＣＰ接続として分類される必要があるか、または非信頼ＴＣＰ接続として分類される必要があるかを示す。
そして、特定されたシグネチャが、シグネチャデータベースに事前に記憶されたいずれのシグネチャとも一致しない場合、ユーザ認証手順が実行され、特定されたシグネチャはシグネチャデータベースに追加される。
有効なユーザ認証データがユーザ認証手順内で受信される場合、特定されたシグネチャには、好ましくは、シグネチャデータベースにおいて、任意の対応するＴＣＰ接続が信頼ＴＣＰ接続として分類される必要があることを示す安全性インジケータが関連付けられる。
有効なユーザ認証データがユーザ認証手順内で受信されない場合、特定されたシグネチャには、好ましくは、シグネチャデータベースにおいて、任意の対応するＴＣＰ接続が非信頼ＴＣＰ接続として分類される必要があることを示す安全性シンジケータが関連付けられる。
ユーザの制御下にないアプリケーション（例えば、マルウェア、ルートキット）は、有効なユーザ認証データを提供することができないため、シグネチャデータベースには、ＨＴＴＰクライアントアプリケーションに関してユーザの環境を表すシグネチャが埋められる。
有効なユーザ認証データが受信される場合、正当なＨＴＴＰクライアントアプリケーションを識別することができ、次に、任意の対応するＴＣＰ接続が信頼ＴＣＰ接続として分類される必要があることを示す安全性インジケータが関連付けられる。
一方、有効なユーザ認証データが受信されない場合、ユーザの制御下になりＨＴＴＰクライアントアプリケーションを識別することができ、任意の対応するＴＣＰ接続が非信頼ＴＣＰ接続として分類される必要があることを示す安全性インジケータが関連付けられる。

好ましい実施形態では、シグネチャは、ＨＴＴＰ要求メッセージ内のＨＴＴＰ必須ヘッダの有効存在、ＨＴＴＰ要求メッセージ内のＨＴＴＰ任意選択的ヘッダの有効存在、ＨＴＴＰ必須ヘッダがＨＴＴＰ要求メッセージ内で現れるシーケンス、およびＨＴＴＰ必須ヘッダの幾つかの各値に基づく。
実際に、ユーザの制御下にない大半のアプリケーションは、ＨＴＴＰヘッダ内の正確な記入、より詳細には、ＨＴＴＰ必須ヘッダが前記アプリケーションによって生成されたＨＴＴＰ要求メッセージ内で表されるシーケンスに注意を払わない。
換言すれば、正当なＨＴＴＰクライアントアプリケーションおよび疑いのあるＨＴＴＰクライアントアプリケーションは通常、ＨＴＴＰヘッダに同じようには記入せず、ＨＴＴＰ必須ヘッダを同じ順序（すなわち、ＨＴＴＰ必須ヘッダのシーケンス）では提示しない。
したがって、この態様を使用して、前記ＨＴＴＰ要求メッセージが属するＨＴＴＰセッションのシグネチャを構築し、ＨＴＴＰセッションのシグネチャは、ＴＣＰ接続の信頼特徴または非信頼特徴（すなわち、ＨＴＴＰセッションに参加しているＨＴＴＰクライアントアプリケーションの信頼特徴または非信頼特徴）を表す。

図１は、本発明を実施し得る通信システムを概略的に表す。

通信システムは、分析デバイス１３０を備える。分析デバイス１３０は、少なくとも１つの第１のＨＴＴＰデバイス（例えばウェブサーバ）と、少なくとも１つの第２のＨＴＴＰデバイス（例えばウェブクライアント）との間でＨＴＴＰトラフィックが運ばれる経路に配置されるＨＴＴＰトラフィックは、ＴＣＰ接続内で搬送される。

図１に示される特定の実施形態では、分析デバイス１３０は、通信デバイス１００内に含まれる。通信デバイス１００は、第１の通信ネットワーク１０１および第２の通信ネットワーク１０２を相互接続するように構成される。第１のデバイスはそれぞれ、第１の通信ネットワーク１０１に接続され、第２のデバイスはそれぞれ、第２の通信ネットワーク１０２に接続される。図１は、１つの第１のデバイス１１０および１つの第２のデバイス１２０を例示的に示す。

したがって、通信デバイス１００は、通信デバイス１００を介して送信されるＴＣＰセグメントを分析デバイス１３０に転送するように更に構成され、それにより、分析デバイス１３０が、ＴＣＰセグメントによって運ばれているＨＴＴＰトラフィックを検出できるようにする。

通信デバイス１００は、通常、住居用ゲートウェイデバイスである。第２の通信ネットワーク１０２はローカルエリアネットワーク（ＬＡＮ）であり、第１の通信ネットワーク１０１はインターネットである。通信デバイス１００は、より多くの通信ネットワークを相互接続し得る。通信デバイス１００は、ＩＰルータ、Ｗｉ−Ｆｉ（登録商標）アクセスポイント、またはＷｉ−Ｆｉ（登録商標）アクセスポイントを実施しているルータとし得る。

通信システムは、監督デバイス１２１を更に備え得る。監督デバイス１２１は、分析デバイス１３０にアクセス可能にされる。一実施形態では、通信デバイス１００が住宅用ゲートウェイデバイスであり、第２の通信ネットワーク１０２がＬＡＮである場合、監督デバイス１２１は、好ましくは、前記ＬＡＮに配置される。
監督デバイス１２１は、分析デバイス１３０からＬＡＮを介してアラーム、すなわちメッセージの形態でのアラームを受信するように構成される。したがって、監督デバイス１２１は、前記アラームを表す情報をユーザに提供することが可能である。
監督デバイス１２１は、図６に関して以下詳述するユーザ認証手順の範囲において、分析デバイス１３０の代理としてユーザと対話するように更に構成し得る。

図２は、分析デバイス１３０のハードウェアアーキテクチャを概略的に表す。示されるアーキテクチャによれば、分析デバイス１３０は、通信バス２１０によって相互接続された以下の構成要素を備える：プロセッサ、マイクロプロセッサ、マイクロコントローラ、またはＣＰＵ（中央演算処理装置）２００、ＲＡＭ（ランダムアクセスメモリ）２０１、ＲＯＭ（読み取り専用メモリ）２０２、ＨＤＤ（ハードディスクドライブ）２０３、またはＳＤ（セキュアデジタル)カードリーダ等の記憶手段に記憶された情報を読み出すように構成される任意の他のデバイス、ならびに分析デバイス１３０を、例えば、第１の通信ネットワーク１０１および第２の通信ネットワーク１０２等の少なくとも１つの通信ネットワークに接続できるようにする通信インターフェースのセット２０４。

ＣＰＵ２００は、ＲＯＭ２０２、ＳＤカード等の外部メモリ、またはＨＤＤ２０３からＲＡＭ２０１にロードされた命令を実行することが可能である。分析デバイス１３０が電源投入された後、ＣＰＵ２００は、ＲＡＭ２０１から命令を読み出し、これらの命令を実行することが可能である。命令は、ＣＰＵ２００に後述するアルゴリズムのいくつかまたは全てのステップを実行させる１つのコンピュータプログラムを形成する。

後述するアルゴリズムのありとあらゆるステップは、ＰＣ（パーソナルコンピュータ）、ＤＳＰ（デジタル信号プロセッサ）、もしくはマイクロコントローラ等のプログラマブル計算マシンによる命令セットまたはプログラムセットの実行により、ソフトウェアにおいて実施してもよく、またはＦＰＧＡ（フィールドプログラマブルゲートアレイ）もしくはＡＳＩＣ（特定用途向け集積回路）等のマシンもしくは専用構成要素によってハードウェアにおいて実施してもよい。

図３は、分析デバイス１３０のモジュール式構成の例を概略的に表す。

分析デバイス１３０は、送受信モジュール３０１を備える。送受信モジュール３０１は、通信デバイス１００が接続された各通信ネットワークからＴＣＰセグメントを受信するように構成されるとともに、必要な場合、前記ＴＣＰセグメントが各アドレスに向けたルートを続けることができるように、受信したＴＣＰセグメントを伝搬するように構成される。
送受信モジュール３０１は、通信デバイス１００が接続された各通信ネットワークからＵＤＰ（標準文書ＲＦＣ７６８によって定義されるような「User Datagram Protocol: ユーザデータグラムプロトコル」）データグラムを受信し、前記ＵＤＰデータグラムがルートを続けることができるように、受信したＵＤＰデータグラムを伝搬するように更に構成し得る。

分析デバイス１３０は、各オープンＴＣＰ接続の状態監視の実行、単一のＨＴＴＰ要求メッセージをセグメント化された様式で運ぶＴＣＰセグメントの再組み立てを担うＴＣＰ分析モジュール３０２を更に備える。そうするために、ＴＣＰ分析モジュール３０２は、ＴＣＰセグメントを送受信モジュール３０１から受信するように構成される。

ＴＣＰ分析モジュール３０２は、非ＨＴＴＰ要求メッセージに対応するＴＣＰセグメントを検出し、前記ＴＣＰセグメントがアドレスに向けたルートを続けることができるように、前記ＴＣＰセグメントを送受信モジュール３０１に返送するように更に構成される。ＴＣＰ分析モジュール３０２は、ＨＴＴＰ要求メッセージに対応するＴＣＰセグメントを検出し、ＨＴＴＰ要求メッセージを更に分析するために、前記ＴＣＰセグメントをＵＲＬ／ＩＰベースの分類モジュール３０３に送信するように更に構成される。

一実施形態では、前記ＨＴＴＰ要求メッセージは、ＵＲＬ／ＩＰベースの分類モジュール３０３に提供するために、ＴＣＰ分析モジュール３０２によってコピーされ、次に、ＴＣＰ分析モジュール３０２は、ＴＣＰ分析モジュール３０２によって受信されるものと同じシーケンス（すなわち、順序）でＴＣＰセグメントを伝搬するように構成される。したがって、ＴＣＰ接続の形態および待ち時間への分析デバイス１３０の影響は制限される。

別の実施形態では、分析デバイス１３０によって分析されると、前記ＨＴＴＰ要求メッセージは、ＴＣＰ分析モジュール３０２に再び提供され、ＴＣＰ分析モジュール３０２は次に、他のＴＣＰセグメントを保留にして、ＴＣＰ分析モジュール３０２によって受信されたものと同じシーケンス（すなわち、順序）でのＴＣＰセグメントの伝搬を保証するように構成される。したがって、ＴＣＰ接続の形態への分析デバイス１３０の影響は制限され、待ち時間のみがわずかに影響を受ける。

更に別の実施形態では、前記ＨＴＴＰ要求メッセージは、信頼ＴＣＰ接続に属するものとしてそれぞれ分類される場合、ＴＣＰ分析モジュール３０２に再び提供される。前記ＨＴＴＰ要求メッセージが非信頼ＴＣＰ接続に属するものとしてそれぞれ分類される場合、ＴＣＰ分析モジュール３０２に通知が送信される。
ＴＣＰ分析モジュール３０２は、この場合、分析デバイス１３０が非信頼ＴＣＰ接続からＨＴＴＰ要求メッセージを取り下げない限り、他のＴＣＰセグメントを保留にして、ＴＣＰ分析モジュール３０２によって受信されたものと略同じシーケンス（すなわち、順序）でのＴＣＰセグメントの伝搬を保証するように構成される。

分析デバイス１３０は、ＵＲＬ／ＩＰベースの分類モジュール３０３を更に備える。
ＵＲＬ／ＩＰベースの分類モジュール３０３は、ＴＣＰ接続によって運ばれるＴＣＰセグメントに含まれるＩＰ宛先アドレス値および／またはＵＲＬに従ってＴＣＰ接続を分類するように構成される。
ＵＲＬ／ＩＰベースの分類モジュール３０３は、ＴＣＰ分析モジュール３０２からＨＴＴＰ要求メッセージを受信するように構成される。
ＵＲＬ／ＩＰベースの分類モジュール３０３は、ＨＴＴＰ要求メッセージに含まれるＩＰ宛先アドレスおよび／またはＵＲＬを、ＩＰアドレスデータベース３１０および／またはＵＲＬデータベース３１１にそれぞれ含まれる情報と比較するように構成される。
ＩＰアドレスデータベース３１０に記憶された各ＩＰアドレスおよびＵＲＬデータベース３１１に記憶された各ＵＲＬには、安全性インジケータが関連付けられる。
「０」に等しい安全性インジケータは、対応するＩＰアドレスを有するか、または対応するＵＲＬがポイントするホストが信頼できることを意味する。したがって、対応するＴＣＰ接続は信頼接続として見なされる。
「０」とは異なる安全性インジケータは、対応するＩＰアドレスを有するか、または対応するＵＲＬがポイントするホストが信頼できないこと、すなわち、非信頼であることを意味し得る。したがって、対応するＴＣＰ接続は非信頼接続と見なされる。

ＩＰアドレスは、例えば、分析デバイス１３０のユーザインターフェースを使用することにより、管理者によってＩＰアドレスデータベース３１０に入力される。
そのようなＩＰアドレスは、ＩＰアドレスデータベース３１０または分析デバイス１３０の製造プロセス中に記憶することもできる。
そのようなＩＰアドレスは、第１の通信ネットワーク１０１等の通信ネットワークからダウンロードすることもできる。
そのようなＩＰアドレスは、図７に関して以下に詳述するように、ＩＰアドレスデータベース３１０に自動的に追加されることもできる。

ＵＲＬは、例えば、分析デバイス１３０のユーザインターフェースを使用することにより、管理者によってＵＲＬデータベース３１１に入力される。
そのようなＵＲＬは、ＵＲＬデータベース３１１または分析デバイス１３０の製造プロセス中に記憶することもできる。
そのようなＵＲＬは、第１の通信ネットワーク１０１等の通信ネットワークからダウンロードすることもできる。

分析デバイス１３０は、ＨＴＴＰシグネチャベースの分類モジュール３０４を更に備える。
ＨＴＴＰシグネチャベースの分類モジュール３０４は、ＨＴＴＰ要求メッセージのＨＴＴＰヘッダに含まれる情報から構築されるＨＴＴＰセッションシグネチャに従ってＴＣＰ接続を分類するように構成される。
ＨＴＴＰシグネチャベースの分類モジュール３０４は、ＵＲＬ／ＩＰベースの分類モジュール３０３から、ＵＲＬ／ＩＰベースの分類モジュール３０３が事前に分類することができなかった任意のＨＴＴＰ要求メッセージを受信するように構成される。
ＨＴＴＰシグネチャベースの分類モジュール３０４は、前記シグネチャをシグネチャデータベース３１２に記憶されたシグネチャと比較して、ＴＣＰ接続が信頼であるか、または非信頼であるかを判断するように構成される。

好ましい実施形態では、ＨＴＴＰシグネチャベースの分類モジュール３０４は、
ＨＴＴＰ要求メッセージ内のＨＴＴＰ必須ヘッダおよびＨＴＴＰ任意選択的ヘッダの有効存在を表す情報と、
ＨＴＴＰ必須ヘッダがＨＴＴＰ要求メッセージ内に現れるシーケンスと、
ＨＴＴＰ必須ヘッダの幾つかに示される値と
から、シグネチャを構築するように構成される。

一実施形態では、分析デバイス１３０は、ＵＲＬ／ＩＰベースの分類モジュール３０３およびＴＣＰ分析モジュール３０２を備えず、ＨＴＴＰシグネチャベースの分類モジュール３０４と直接対話する。

分析デバイス１３０は、ユーザ認証モジュール３０５を更に備える。
ユーザ認証モジュール３０５は、認証手順を実行して、ＨＴＴＰシグネチャベースの分類モジュール３０４が事前に分類することができなかったＴＣＰ接続が、信頼であるか、または非信頼であるかを判断するように構成される。
ユーザ認証モジュール３０５は、ＨＴＴＰシグネチャベースの分類モジュール３０４が、ＴＣＰ接続についてシグネチャデータベース３１２内の少なくとも１つの一致するシグネチャを見つけることができなかった場合、認証手順を起動するように構成される。
したがって、ユーザ認証モジュール３０５は、ＨＴＴＰシグネチャベースの分類モジュール３０４から、ＨＴＴＰシグネチャベースの分類モジュール３０４が事前に分類することができなかった旨の任意のＨＴＴＰ要求メッセージを受信するように構成される。
ユーザ認証モジュール３０５は、ユーザ認証の成功に起因して信頼接続として見なされるＴＣＰ接続のシグネチャでシグネチャデータベース３１２を更新するように更に構成され、好ましくは、ユーザ認証の不成功に起因して非信頼接続として見なされるＴＣＰ接続のシグネチャでシグネチャデータベース３１２を更新するように構成される。

分析デバイス１３０は、アラーム生成モジュール３０６を更に備える。
アラーム生成モジュール３０６は、ＵＲＬ／ＩＰベースの分類モジュール３０３、ＨＴＴＰシグネチャベースの分類器３０４、またはユーザ認証モジュール３０５によって報告されるエラーイベントに基づいてアラーム指示を提供するように構成される。
したがって、アラーム生成モジュール３０６は、ＵＲＬ／ＩＰベースの分類モジュール３０３、ＨＴＴＰシグネチャベースの分類器３０４、およびユーザ認証モジュール３０５からエラーイベントを受信するように構成される。

一実施形態では、分析デバイス１３０は、ＵＤＰ分析モジュール３０７およびドメイン名分析モジュール３０８を更に備える。ＵＤＰ分析モジュール３０７は、ＵＤＰデータグラム内のＤＮＳ（「Domain Name System: ドメイン名システム」）サーバ応答を検出し、前記ＤＮＳサーバ応答をドメイン名分析モジュール３０８に提供することを担う。
そうするために、ＵＤＰ分析モジュール３０７は、ＵＤＰデータグラムを送受信モジュール３０１から受信するように構成される。
一実施形態では、前記ＤＮＳサーバ応答は、ＵＤＰ分析モジュール３０７によってコピーされて、前記ＤＮＳサーバ応答をドメイン名分析モジュール３０８に提供し、次に、ＵＤＰ分析モジュール３０７は、ＵＤＰ分析モジュール３０７によって受信される物と同じシーケンス（すなわち、順序）でＵＤＰデータグラムを伝搬するように構成される。
したがって、ＵＤＰデータフローの形態および待ち時間への分析デバイス１３０の影響は制限される。
別の実施形態では、ドメイン名分析モジュール３０８によって分析されると、前記ＵＤＰデータグラムは、前記ＵＤＰデータグラムを伝搬するために、再びＵＤＰ分析モジュール３０７に提供される。
ＵＤＰはデータグラム順序に関して柔軟であるコネクションレス伝送プロトコルであるため、ＵＤＰデータグラムは、受信されるものと同じシーケンス（すなわち、順序）で伝搬しないことがある。

ドメイン名分析モジュール３０８は、標準文書ＲＦＣ１０３５およびＲＦＣ３５９６において定義され、ＤＮＳサーバ応答に含まれるＡおよび／またはＡＡＡＡレコードを調べるように構成される。前記レコードは、ドメイン名情報とのＩＰアドレスの関連付けを含む。
ドメイン名分析モジュール３０８は、ＤＮＳサーバ応答に含まれるドメイン名情報がドメイン名データベース３１３に存在するか否かをチェックするように構成される。
ドメイン名データベース３１３に記憶される各ドメイン名情報には、安全性インジケータが関連付けられる。
「０」に等しい安全性インジケータは、ドメイン名が信頼できることを意味する。「０」とは異なる安全性インジケータは、ドメイン名が信頼できない、すなわち、非信頼であることを意味する。
ドメイン名情報は、例えば、分析デバイス１３０のユーザインターフェースを使用することにより、管理者によってドメイン名データベース３１３に入力される。
ドメイン名情報は、ドメイン名データベース３１３または分析デバイス１３０の製造プロセス中に記憶することもできる。
ドメイン名情報は、第１の通信ネットワーク１０１等の通信ネットワークからダウンロードすることもできる。
ドメイン名分析モジュール３０８は、ＤＮＳサーバ応答に含まれるドメイン名情報がドメイン名データベース３１３に存在し、レコードに含まれるＩＰアドレスがＩＰアドレスデータベース３１０にまだ存在していない場合、新しいエントリをＩＰアドレスデータベース３１０に追加するように更に構成される。
前記新しいエントリは、レコードに含まれるＩＰアドレスであり、ドメイン名データベース３１３に記憶されたドメイン名情報に関連付けられた安全性インジケータが関連付けられる。これにより、ＩＰアドレスデータベース３１０を自動的に埋めることができる。
特定の実施形態では、予め定義される時間が前記新しいエントリに関連付けられる。前記エントリは、前記予め定義される時間が切れた後、ＩＰアドレスデータベース３１０から分析デバイス１３０によって除去される。

ＩＰアドレスデータベース３１０、ＵＲＬデータベース３１１、シグネチャデータベース３１２、および／またはドメイン名データベース３１３は、分析デバイス１３０に統合し得る。
代替的には、ＩＰアドレスデータベース３１０、ＵＲＬデータベース３１１、シグネチャデータベース３１２、および／またはドメイン名データベース３１３は、別個に実施され、次に、例えば通信ネットワークを介して分析デバイス１３０に接続してもよい。

図４は、シグネチャデータベース３１２にシグネチャを記憶する例としての構造４００を概略的に表す。
シグネチャデータベース３１２に記憶されたシグネチャは少なくとも、
ＨＴＴＰ要求メッセージに存在することが予期されるＨＴＴＰ必須ヘッダを表す情報と、
ＨＴＴＰ要求メッセージに存在することが予期されるＨＴＴＰ任意選択的ヘッダを表す情報と、
ＨＴＴＰ必須ヘッダがＨＴＴＰ要求メッセージに現れるシーケンスを表す情報と、
ＨＴＴＰ要求メッセージに存在するＨＴＴＰ必須ヘッダの予め定義されるフィールドに含まれる値を表す情報と
を含む。

シグネチャデータベース３１２に記憶されたシグネチャは、図４に示される構造４００等のより多くの情報を含み得る。図４に示される構造４００は、以下を含む。
−ＨＴＴＰ必須ヘッダの第１のリスト４１１、
−ＨＴＴＰ任意選択的ヘッダの第２のリスト４１２、
−チェックされる値を含む予め定義されるフィールドを有するＨＴＴＰ必須ヘッダの第３のリスト４１３、
−ＨＴＴＰ必須ヘッダが現れるシーケンスを表す情報４１４、
−チェックされる値を含む予め定義されるフィールドを有するＨＴＴＰ必須ヘッダの第３のリスト４１３の許可される値のセット４２２、
−安全性インジケータ４２３、および
−単一のＩＰソースアドレスに制限することができるＩＰソースアドレスのセットを表す情報４２４。

ＨＴＴＰ必須ヘッダの第３のリスト４１３の許可された値が、文字列または正規表現であり得ることに留意されたい。

シグネチャ４００はプロファイル４０１に基づく。
プロファイル４０１は、
ＨＴＴＰ必須ヘッダの第１のリスト４１１と、
ＨＴＴＰ任意選択的ヘッダの第２のリスト４１２と、
ＨＴＴＰ必須ヘッダの第３のリスト４１３と、
ＨＴＴＰ必須ヘッダが現れるシーケンスを表す情報４１４と
を含む。
プロファイルは、例えば、分析デバイス１３０のユーザインターフェースを使用することにより、管理者によってシグネチャデータベース３１２に入力される。
プロファイル４０１は、シグネチャデータベース３１２または分析デバイス１３０の製造プロセス中に記憶することもできる。
プロファイル４０１は、第１の通信ネットワーク１０１等の通信ネットワークからダウンロードすることもできる。
単一のプロファイルは幾つかのシグネチャによって共有し得る。

シグネチャは、上述した認証手順に続き、ユーザ認証モジュール３０５によってシグネチャデータベース３１２に入力される。
ＩＰソースアドレスのセットを表す情報４２４は、シグネチャを追加または更新する際にユーザ認証モジュール３０５によって出願され、シグネチャがシグネチャデータベース３１２に追加されたＨＴＴＰクライアントアプリケーションを実施中のデバイスのＩＰアドレスを定義する。

ウェブブラウザ等の正当なＨＴＴＰクライアントアプリケーションは一般に、ＴＣＰ接続毎に同じＨＴＴＰ必須ヘッダのリスト、同じＨＴＴＰ任意選択的ヘッダのリスト、ＨＴＴＰ必須ヘッダが現れる同じシーケンスを使用する。
さらに、特定の値は、前記正当なＨＴＴＰクライアントアプリケーションによって生成されるＨＴＴＰ要求メッセージのＨＴＴＰ必須ヘッダの同じ予め定義されるフィールドに含まれる。
したがって、図４に示されるようなプロファイルに頼り、シグネチャデータベース３１２に挿入されるシグネチャの作成を簡易化することができる。

図５は、ＴＣＰ接続を分類する、分析デバイス１３０によって実行されるアルゴリズムを概略的に表す。

ステップＳ５００において、分析デバイス１３０は、第２のデバイス１２０から第１のデバイス１１０に送信されたＴＣＰセグメントを受信する。実際に、既に述べたように、分析デバイス１３０は、第１のデバイス１１０と第２のデバイス１２０とのデータ経路に配置される。図３に示されるモジュール式構成の範囲において、ステップＳ５００は送受信モジュール３０１によって実行される。

続くステップＳ５０１において、分析デバイス１３０は、受信したＴＣＰセグメントに基づいて再組み立てを実行し、再組み立て後、ＴＣＰセグメント内のＨＴＴＰセッションのＨＴＴＰ要求メッセージを検出しようとする。図３に示されるモジュール式構成の範囲において、ステップＳ５０１は、ＴＣＰ分析モジュール３０２によって実行される。

続くステップＳ５０２において、分析デバイス１３０は、ＨＴＴＰセッションのシグネチャを構築できるように、検出されたＨＴＴＰ要求メッセージから情報を取得する。
好ましい実施形態では、分析デバイス１３０は、少なくとも、
ＨＴＴＰ要求メッセージに含まれるＨＴＴＰ必須ヘッダおよびＨＴＴＰ任意選択的ヘッダのそれぞれを表す情報と、
前記ＨＴＴＰ必須ヘッダがＨＴＴＰ要求メッセージ内で現れるシーケンスを表す情報と、
ＨＴＴＰ必須ヘッダのフィールドに含まれる値を表す情報と
を取得する。

分析デバイス１３０は、
ＩＰソースアドレスＨＴＴＰ要求メッセージ、すなわち、ＨＴＴＰ要求メッセージを発したデバイスのＩＰアドレスを表す情報と、
ＩＰ宛先アドレス、すなわち、ＨＴＴＰ要求メッセージが意図されたデバイスのＩＰアドレスを表す情報と、
ＨＴＴＰ要求メッセージに含まれるＵＲＬを表す情報と
を更に取得し得る。
ＩＰソースアドレスを表す情報は、シグネチャデータベース３１２に記憶されたシグネチャについて第２のデバイス１２０が事前に認証されたか否かを任意選択的に判断する（認証手順を実行したことにより）ために使用される。
ＩＰ宛先アドレスを表す情報およびＵＲＬを表す情報は、ＩＰ宛先アドレスに対応する第１のデバイス１１０が信頼デバイスであるかまたは非信頼デバイスであるかを任意選択的に判断するために、使用される。

続く任意選択的なステップＳ５０３において、分析デバイス１３０は、検出されたＨＴＴＰ要求メッセージからステップＳ５０２において得られたＩＰ宛先アドレスをチェックする。これを達成するために、分析デバイス１３０は、前記ＩＰ宛先アドレスをＩＰアドレスデータベース３１０の内容と比較する。
図３に示されるモジュール式構成の範囲において、ステップＳ５０３はＵＲＬ／ＩＰベースの分類モジュール３０３によって実行される。
ＩＰ宛先アドレスがＩＰアドレスデータベース３１０に含まれており、関連付けられた安全性インジケータが「０」とは異なる場合、ＴＣＰ接続が非信頼であることを意味し、したがって、エラーイベントがアラーム生成器３０６に向けて生成される。
そのようなＩＰ宛先アドレスに頼ることによるＴＣＰ接続の分類は、ソフトウェア更新ＨＴＴＰクライアントアプリケーション等の１つまたは少数のドメインにアクセスする正当なＨＴＴＰクライアントアプリケーションの分類をより容易にすることもできる。

続くステップＳ５０４において、分析デバイス１３０は、ステップＳ５０２において得られたＩＰ宛先アドレスがＩＰアドレスデータベース３１０に含まれているか否かをチェックする。
ステップＳ５０２において得られたＩＰ宛先アドレスがＩＰアドレスデータベース３１０に含まれている場合、ステップＳ５１０が実行され、その他の場合、ステップＳ５０５が実行される。

任意選択的なステップＳ５０５において、分析デバイス１３０は、検出されたＨＴＴＰ要求メッセージからステップＳ５０２において得られたＵＲＬをチェックする。これを達成するために、分析デバイス１３０は、前記ＵＲＬをＵＲＬデータベース３１１の内容と比較する。
図３に示されるモジュール式構成の範囲において、ステップＳ５０５は、ＵＲＬ／ＩＰベースの分類モジュール３０３によって実行される。
ＵＲＬがＵＲＬデータベース３１１に含まれ、関連付けられた安全性インジケータが「０」とは異なる場合、ＴＣＰ接続が非信頼であることを意味し、したがって、エラーイベントがアラーム生成器３０６に向けて生成される。そのようなＵＲＬに頼ることによるＴＣＰ接続の分類は、ソフトウェア更新ＨＴＴＰクライアントアプリケーション等の１つまたは少数のドメインにアクセスする正当なＨＴＴＰクライアントアプリケーションの分類をより容易にすることもできる。

続くステップＳ５０６において、分析デバイス１３０は、ステップＳ５０２において得られたＵＲＬがＵＲＬデータベース３１１に含まれているか否かをチェックする。
ステップＳ５０２において得られたＵＲＬがＵＲＬデータベース３１１に含まれている場合、ステップＳ５１０が実行され、その他の場合、ステップＳ５０７が実行される。

ステップＳ５０７において、分析デバイス１３０は、検出されたＨＴＴＰ要求メッセージからステップＳ５０２において得られた情報から、ＨＴＴＰセッションのシグネチャを構築する。分析デバイス１３０は、構築されたシグネチャを更にチェックする。これを達成するために、分析デバイス１３０は、構築されたシグネチャをシグネチャデータベース３１２の内容と比較する。
図３に示されるモジュール式構成の範囲において、ステップＳ５０７は、潜在的にユーザ認証モジュール３０５と併せて、ＨＴＴＰシグネチャベースの分類モジュール３０４によって実行される。
ステップＳ５０７の詳細な実施形態は、以下、図６に関して詳述される。
構築されたシグネチャがシグネチャデータベース３１２に含まれており、関連付けられた安全性インジケータが「０」とは異なる場合、ＴＣＰ接続が非信頼であることを意味し、したがって、エラーイベントがアラーム生成器３０６に向けて生成される。

続くステップＳ５０８において、分析デバイス１３０は、構築されたシグネチャがシグネチャデータベース３１２に含まれているか否かをチェックする（前記シグネチャが、ＨＴＴＰ要求メッセージの受信前にシグネチャデータベース３１２に存在していたか、またはシグネチャがユーザ認証モジュール３０５によって追加されたかのいずれかのため）。
構築されたシグネチャがアプリケーションデータベース３１２に含まれている場合、ステップＳ５１０が実行され、その他の場合、ステップＳ５０９が実行される。

ステップＳ５０９において、分析デバイス１３０はアラームを生成する。
図３に示されるモジュール式構成の範囲において、ステップＳ５０９は、検出されたＨＴＴＰ要求メッセージに含まれるＩＰ宛先アドレスおよび／またはＵＲＬをチェックする際にＵＲＬ／ＩＰベースの分類モジュール３０３によって生成されるエラーイベントから、ＨＴＴＰシグネチャベースの分類モジュール３０４によって生成されるエラーイベントから、またはユーザ認証モジュール３０５によって生成されるエラーイベントから、アラーム生成モジュール３０６によって実行される。

ステップＳ５１０において、分析デバイス１３０は、ＩＰアドレスデータベース３１０において見つけられたＩＰアドレス（ステップＳ５１０がステップＳ５０４の実行に続けて実行される場合）、ＵＲＬデータベース３１１において見つけられたＵＲＬ（ステップＳ５１０がステップＳ５０６の実行に続けて実行される場合）、またはシグネチャデータベース３１２において見つけられたシグネチャ（ステップＳ５１０がステップＳ５０８の実行に続けて実行される場合）に関連付けられた安全性インジケータが「０」に等しいか否かをチェックする。

安全性インジケータが「０」とは異なる場合、ＴＣＰ接続が非信頼であることを意味し、したがって、既に述べたように、エラーイベントがアラーム生成器３０６に向けて生成される。したがって、分析デバイス１３０は、ステップＳ５０９を実行することによってアラームを生成する。
そのようなアラームは、分析デバイス１３０が、関わるＴＣＰ接続のＴＣＰセグメントをアドレスに向けたルートで伝搬せずに、前記ＴＣＰセグメントを取りやめることを暗に示し得る。
そのようなアラームは、変形において、分析デバイス１３０が、前記ＴＣＰセグメントの取りやめありまたはなしで、ユーザに向けられたアラーム指示、例えば、光または音を生成することを暗に示し得る。
そのようなアラーム指示の提供は、分析デバイス１３０によって保持されるログファイル内の対応するラインに記入することもできる。

安全インジケータが「０」に等しい場合、ＴＣＰ接続が信頼であることを意味し、ステップＳ５１１が実行され、検出されたＨＴＴＰ要求メッセージは安全と見なされる。

図６は、ＨＴＴＰセッションのシグネチャをチェックし、必要な場合にはシグネチャデータベース３１２を更新する、分析デバイス１３０によって実行されるアルゴリズムを概略的に表す。
図６のアルゴリズムは、ステップＳ５０７の詳細な実施形態である。
図３に示されるモジュール式構成の範囲において、図６のアルゴリズムは、より詳細には、別段のことが示される場合を除き、ＨＴＴＰシグネチャベースの分類モジュール３０４によって実行される。
図６のアルゴリズムは、ステップＳ５０１において検出されたＨＴＴＰ要求メッセージに一致するシグネチャデータベース３１２に記憶されたシグネチャを見つけようとする。

ステップＳ６００において、分析デバイス１３０は、シグネチャデータベース３１２に記憶されたシグネチャを選択する。記憶されたシグネチャは、好ましくは、図４に関して既に詳述したフォーマットに従って構築される。

続くステップＳ６０１において、分析デバイス１３０は、ＩＰソースアドレス、すなわち、ＨＴＴＰ要求メッセージを発したデバイスのＩＰアドレスをチェックして、選択されたシグネチャが前記ＨＴＴＰ要求メッセージに適用可能であるか否かを見つけ出す。

続くステップＳ６０２において、分析デバイス１３０は、前記ＩＰソースアドレスが、選択されたシグネチャ内に規定されたＩＰソースアドレスのセットに含まれるか否かをチェックする。ＩＰソースアドレスが、選択されたシグネチャに規定されたＩＰソースアドレスのセットに含まれる場合、ステップＳ６０３が実行され、その他の場合、ステップＳ６１２が実行される。

ステップＳ６０３において、分析デバイス１３０は、ＨＴＴＰ要求メッセージのＨＴＴＰヘッダをチェックして、選択されたシグネチャにおいて規定される任意のＨＴＴＰ必須ヘッダがＨＴＴＰ要求メッセージに存在するか否かを見つけ出す。

続くステップＳ６０４において、分析デバイス１３０は、選択されたシグネチャにおいて規定された各ＨＴＴＰ必須ヘッダが、ＨＴＴＰ要求メッセージに存在するか否かをチェックする。選択されたシグネチャにおいて規定された各ＨＴＴＰ必須ヘッダがＨＴＴＰ要求メッセージに存在する場合、ステップＳ６０５が実行され、その他の場合、ステップＳ６１２が実行される。

ステップＳ６０５において、分析デバイス１３０は、ＨＴＴＰ要求メッセージのＨＴＴＰヘッダをチェックして、前記ＨＴＴＰヘッダがＨＴＴＰ必須ヘッダの第１のリスト４１１または選択されたシグネチャのＨＴＴＰ任意選択的ヘッダの第２のリスト４１２に存在するか否かを見つけ出す。

続くステップＳ６０６において、分析デバイス１３０は、ＨＴＴＰ要求メッセージの各ＨＴＴＰヘッダが、ＨＴＴＰ必須ヘッダの第１のリスト４１１または選択されたシグネチャのＨＴＴＰ任意選択的ヘッダの第２のリスト４１２に存在するか否かをチェックする。各ＨＴＴＰヘッダが選択されたシグネチャに存在する場合、ステップＳ６０７が実行され、その他の場合、ステップＳ６１２が実行される。

ステップＳ６０７において、分析デバイス１３０は、ＨＴＴＰ要求メッセージのＨＴＴＰ必須ヘッダが現れるシーケンスをチェックして、前記シーケンスが、選択されたシグネチャにおいて規定されたＨＴＴＰ必須ヘッダのシーケンスに一致するか否かを見つけ出す。

続くステップＳ６０８において、分析デバイス１３０は、ＨＴＴＰ要求メッセージのＨＴＴＰ必須ヘッダが現れるシーケンスが、選択されたシグネチャにおいて規定されたＨＴＴＰ必須ヘッダのシーケンスに一致するか否かをチェックする。ＨＴＴＰ要求メッセージのＨＴＴＰヘッダが現れるシーケンスが、選択されたシグネチャにおいて規定されるＨＴＴＰヘッダのシーケンスに一致する場合、ステップＳ６０９が実行され、その他の場合、ステップＳ６１２が実行される。

ステップＳ６０９において、分析デバイス１３０は、ＨＴＴＰ要求メッセージのＨＴＴＰ必須ヘッダに存在する値をチェックして、前記ＨＴＴＰヘッダが選択されたシグネチャにおいて規定される値を含むか否かを見つけ出す。

続くステップＳ６１０において、分析デバイス１３０は、ＨＴＴＰ要求メッセージのＨＴＴＰヘッダが、選択されたシグネチャにおいて規定される値を含むか否かをチェックする。ＨＴＴＰ要求メッセージのＨＴＴＰヘッダが、選択されたシグネチャにおいて規定される値を含む場合、ステップＳ６１１が実行され、その他の場合、ステップＳ６１２が実行される。

ステップＳ６１１において、分析デバイス１３０は、ＨＴＴＰ要求メッセージに対応するシグネチャが、シグネチャデータベース３１２において見つけられたことを考慮する。これは、ＨＴＴＰ要求メッセージが、既に事前に直面したことがあるアプリケーションについてのＴＣＰ接続に属することを意味する。
図４に示されるように、選択されたシグネチャは安全性インジケータを含む。この安全性インジケータは、ステップＳ５１０に関して既に説明したように、ＨＴＴＰ要求メッセージが、信頼されるＴＣＰ接続に属するか否かを判断したために使用される。
図６のアルゴリズムは、次に終了する。

ステップＳ６１２において、分析デバイス１３０は、シグネチャデータベース３１２に記憶された全てのシグネチャが考慮されたか否かをチェックする。シグネチャデータベース３１２に記憶された全てのシグネチャが考慮された場合、ＨＴＴＰ要求メッセージが、シグネチャデータベース３１２に既に記憶されたいかなるシグネチャに対応しないことを意味し、ステップＳ６１３が実行され、その他の場合、ステップＳ６００は、まだ考慮されていない、シグネチャデータベース３１２に記憶されたシグネチャを選択することによって繰り返される。

ステップＳ６１３において、分析デバイス１３０は、認証手順を起動させて、ＨＴＴＰ要求メッセージがユーザによって信頼されるアプリケーションによって送信されたか否かを判断する。図３に示されるモジュール式構成の範囲において、認証手順は、ＨＴＴＰシグネチャベースの分類モジュール３０４による要求される場合、ユーザ認証モジュール３０５によって実行される。

認証手順が成功する場合、ステップＳ６１５において、対応するシグネチャはシグネチャデータベース３１２に追加され、次に、ステップＳ６１１が実行される。シグネチャは信頼ＴＣＰ接続に対応するため、シグネチャデータベース３１２に追加されたシグネチャ内の安全性インジケータは、この場合、「０」に設定される。

認証手順が成功しない場合、ステップＳ６１６において、分析デバイス１３０は、ＨＴＴＰ要求メッセージに対応するシグネチャがシグネチャデータベース３１２において見つけられなかったことを考慮する。そして、図６のアルゴリズムは終了する。したがって、これは、図５のアルゴリズムの範囲において、ＨＴＴＰ要求メッセージがアラームの生成を暗に示すことを意味する。

変形では、認証手順が成功しない場合、ステップＳ６１６において、対応するシグネチャはシグネチャデータベース３１２に追加され、次に、ステップＳ６１１が実行される。
前記シグネチャは非信頼ＴＣＰ接続に対応するため、シグネチャデータベース３１２に追加されたシグネチャ内の安全性インジケータは、この場合、「０」とは異なる値に設定される。
この場合、図６のアルゴリズムは、ＨＴＴＰ要求メッセージがシグネチャデータベース３１２に記憶されたシグネチャに一致することを考慮することにより、終了する。
したがって、これは、図５のアルゴリズムの範囲において、ＨＴＴＰ要求メッセージに一致するシグネチャに関連付けられた安全性インジケータが「０」とは異なる値に設定されるため、ＨＴＴＰ要求メッセージがアラームの生成を暗に示すことを意味する。

認証手順は、ＨＴＴＰ要求メッセージ（事前に分類することができなかった）を生成したＨＴＴＰクライアントアプリケーションが、ユーザの制御下にあるか、またはユーザの制御から隠されているかを判断することを目的とする。
認証手順の目的は、ウェブブラウザ等の正当なアプリケーションをマルウェア、ルートキット、またはユーザの制御外で実行中の任意のソフトウェア等の悪意のあるアプリケーションから明確に区別することである。

一実施形態では、認証手順は以下のようである：分析デバイス１３０は、ＨＴＴＰ要求メッセージを発したデバイスに、分析デバイス１３０によって管理される仮想ＵＲＬにリダイレクトするＨＴＴＰ応答メッセージを送信する。
次に、ＨＴＴＰ要求メッセージを発したデバイスは、別のＨＴＴＰ要求メッセージを仮想ＵＲＬに送信することによって反応し、分析デバイス１３０は、ログイン／パスワードＨＴＭＬ（「ハイパーテキストマークアップ言語」）フォームと、好ましくは、プロファイル選択フィールドとを含むウェブページで答える。
したがって、ユーザは、有効なログインおよび有効なパスワード、すなわち、分析デバイス１３０に事前に知られたログインおよびパスワードでフォームに記入することが予期される。
ユーザはまた、一致するプロファイルの予め定義されたセットの中から、どのプロファイル４０１を適用するかを選択することも予期される。
次に、ＨＴＴＰ要求メッセージを発したデバイスは、ユーザによって入力されたログインおよびパスワードと、もしあれば、選択されたプロファイルとを分析器１３０に送信する。

フォームが有効に記入される場合、分析デバイス１３０は、ＴＣＰ接続が信頼であると見なす。

フォームが無効に記入される場合、分析デバイス１３０は、潜在的には、有効に記入されたフォームを取得した最大試行回数後、ＴＣＰ接続が非信頼であると見なす。

予め定義された時間が切れた後、ウェブページへの応答が受信されない場合、分析デバイス１３０は、ＴＣＰ接続は非信頼であると見なす。

プロセスを簡易化するために、ログイン／パスワード手法は、マシンではなく人間によってのみ解くことが意図されるパズル（「ＣＡＰＴＣＨＡ」として知られ、これは、「コンピュータと人間を区別する完全に自動化された公開チューリングテスト(Completely Automated Public Turing test to tell Computers and Humans Apart)」を表す）手法で置換することができる。そのようなパズルは、ＨＴＴＰクライアントアプリケーションが人間であるか否かを判断するために計算技術で使用される一種のチャレンジ−レスポンステストである。主な利点は、ログインおよびパスワード情報を記憶するデータベースの保持を回避することである。

図３に示されるモジュール式構成の範囲において、分析デバイス１３０に対する認証手順のステップは、ユーザ認証モジュール３０５によって実行される。

別の実施形態では、認証は、監督デバイス１２１と連携して実行される。この場合、ＨＴＴＰ要求メッセージは、認証手順中、保留される。
次に、分析デバイス１３０は、監督デバイス１２１と通信して、ユーザ認証を要求し、したがって、ユーザは、監督デバイスを介してフォームに記入することが予期される。
ＨＴＴＰ要求メッセージから抽出された追加情報もユーザに表示して、ユーザがどのＨＴＴＰクライアントアプリケーションが認証手順に関わっているかを見つけ出すのを助け得る。
したがって、信頼アプリケーション、すなわち、信頼ＴＣＰ接続の宣言を可能にするが、前記アプリケーションは、ウェブページの表示が可能ではないマシンで実行される。

認証手順の範囲でのユーザとの対話は、分析デバイス１３０のユーザインターフェースを介して実行することもできる。したがって、信頼アプリケーション、すなわち、信頼ＴＣＰ接続を宣言することもできるようにするが、前記アプリケーションは、ウェブページの表示が可能ではないマシンで実行される。

シグネチャデータベース３１２に記憶するシグネチャを構築するために、分析デバイス１３０は、適合するプロファイルのリストを選択し、ＨＴＴＰ要求メッセージが、選択されたプロファイルがある場合、選択された各プロファイルに準拠することをチェックする。
分析デバイス１３０は、選択された各プロファイル内の全てのＨＴＴＰ必須ヘッダが、ＨＴＴＰ要求メッセージに存在すること、およびＨＴＴＰ要求メッセージ内の全てのヘッダが、選択された各プロファイル内のＨＴＴＰ必須ヘッダまたはＨＴＴＰ任意選択的ヘッダとして列挙されていることをチェックする。
２つ以上のプロファイルが選択される場合、ユーザは、分析デバイス１３０によって選択されたプロファイルのリストの中から１つのプロファイルを選択することが予期される。
分析デバイス１３０は、ユーザによって選択されるプロファイルにおいて、値をチェックする必要があるＨＴＴＰ必須ヘッダのリストに属するＨＴＴＰ必須ヘッダの値を更に取得する。
安全性インジケータは、信頼ＨＴＴＰクライアントアプリケーション、すなわち、信頼ＴＣＰ接続を示すために、「０」に設定され、非信頼ＨＴＴＰクライアントアプリケーション、すなわち、非信頼ＴＣＰ接続を示すために、「０」とは異なる値に設定される。
分析デバイス１３０は、ＨＴＴＰ要求メッセージを発したデバイスのＩＰアドレスを更に取得する。
次に、分析デバイス１３０は、それに従ってシグネチャ構造４００を記入する。
シグネチャが、ＨＴＴＰ要求メッセージを発したデバイスのＩＰアドレスが示されていない場合を除き、シグネチャデータベース３１２に既に存在する場合、分析デバイス１３０は、シグネチャデータベース３１２に記憶された前記シグネチャに含まれるＩＰソースアドレスセットを更新する。
これは、図４に示されるシグネチャフォーマットに従って、アイテム４１１、４１２、４１３、４１４、４２２、および４２３が、アイテム４２４において識別されるデバイスで実行中のＨＴＴＰクライアントアプリケーションについて共有されることを除き、シグネチャを単に追加することに対応する。

図７は、ＩＰアドレスデータベース３１１に新しいエントリを追加する、分析デバイス１３０によって実行されるアルゴリズムを概略的に表す。図３に示されるモジュール式構成の範囲では、図７のアルゴリズムは、より詳細には、別段のことが記される場合を除き、ドメイン名分析モジュール３０８によって実行される。

ステップＳ７００において、分析デバイス１３０はＵＤＰデータグラムを受信する。図３に示されるモジュール式構成の範囲において、ステップＳ７０１はＵＤＰ分析モジュール３０７によって実行される。

続くステップＳ７０１において、分析デバイス１３０は、受信したＵＤＰデータグラム内のＤＮＳサーバ応答を検出しようとする。図３に示されるモジュール式構成の範囲において、ステップＳ７０１もＵＤＰ分析モジュール３０７によって実行される。

続くステップＳ７０２において、分析デバイス１３０は、検出されたＤＮＳサーバ応答から情報を取得する。そのような情報は、ドメイン名情報とのＩＰアドレスの関連付けを含む、Ａ型（ＩＰｖ４アドレス）またはＡＡＡＡ型（ＩＰｖ６アドレス）のレコードである。

続くステップＳ７０３において、分析デバイス１３０は、検出されたＤＮＳサーバ応答から取得されたドメイン名情報が、ドメイン名データベース３１３に存在するか否かをチェックする。

続くステップＳ７０４において、分析デバイス１３０は、検出されたＤＮＳサーバ応答から取得されたドメイン名情報が、ドメイン名データベース３１３から検索されたか否かをチェックする。検出されたＤＮＳサーバ応答から取得されたドメイン名情報が、ドメイン名データベース３１３から検索された場合、ステップＳ７０６が実行され、その他の場合、ステップＳ７０５が実行され、図７のアルゴリズムは終了する。

ステップＳ７０６において、分析デバイス１３０は、新しいエントリをＩＰアドレスデータベース３１０に追加する。新しいエントリは、ドメイン名情報に関連付けてレコードに含まれるＩＰアドレスに対応する。
次に、前記ＩＰアドレスには、ＩＰアドレスデータベース３１０において、ドメイン名データベース３１３において前記ドメイン名情報に関連付けられた安全性インジケータに一致する安全性インジケータが関連付けられる。
特定の実施形態では、前記ＩＰアドレスには、予め定義される時間も関連付けられる。その場合、対応するエントリは、前記予め定義される時間が切れた後、分析デバイス１３０によってＩＰアドレスデータベース３１０から除去される。

したがって、図７のアルゴリズムは、ＩＰアドレスデータベース３１０を埋めることができる。ＤＮＳサーバ応答の分析によってＩＰアドレスデータベース３１０を埋める本明細書に記載される原理が、ＨＴＴＰセッションシグネチャの任意の分析から独立して実施し得ることに留意し得る。

Claims (14)

1. 分析デバイスによって実行される、信頼ＴＣＰ接続または非信頼ＴＣＰ接続としてＨＴＴＰトラフィックを搬送するＴＣＰ接続を分類する方法であって、
   前記ＴＣＰ接続によって搬送される前記ＨＴＴＰトラフィック内のＨＴＴＰセッションのＨＴＴＰ要求メッセージを検出することと、
   前記検出されたＨＴＴＰ要求メッセージのヘッダから、前記ＨＴＴＰセッションのシグネチャを構築するための情報を取得することと、
   前記ＨＴＴＰセッションの前記シグネチャを、前記分析デバイスによって事前にシグネチャデータベースに記憶されたシグネチャと比較することと、
   前記ＨＴＴＰセッションの前記シグネチャが、前記シグネチャデータベースに前記分析デバイスによって事前に記憶され、信頼ＨＴＴＰクライアントアプリケーションを表すシグネチャに一致する場合、前記ＴＣＰ接続を信頼接続として分類することと、
   前記ＨＴＴＰセッションの前記シグネチャが、前記シグネチャデータベースに前記分析デバイスによって事前に記憶されたいずれのシグネチャにも一致しない場合、認証データを提供するようにユーザに要求する認証手順を実行することと、
   有効な認証データが前記ユーザによって提供される場合、前記ＨＴＴＰセッションの前記シグネチャを前記シグネチャデータベースに追加し、前記ＨＴＴＰセッションの前記シグネチャは、前記シグネチャデータベース内で信頼ＨＴＴＰクライアントアプリケーションを表し、前記ＴＣＰ接続を信頼接続として分類することと、
   有効な認証データが前記ユーザによって提供されない場合、前記ＴＣＰ接続を非信頼接続として分類することと
   を含み、
   前記認証手順は、
   前記検出されたＨＴＴＰ要求メッセージを発したデバイスに応答を送信することであって、前記応答は、前記検出されたＨＴＴＰ要求メッセージを発した前記デバイスを別のＵＲＬにリダイレクトする、送信することと、
   前記検出されたＨＴＴＰ要求メッセージを発した前記デバイスから、前記別のＵＲＬを参照する別のＨＴＴＰ要求メッセージを受信することと、
   前記別のＨＴＴＰ要求メッセージに応答して、前記ユーザが認証情報を入力することができるウェブページを送信することと、
   有効な認証情報が受信される場合、前記ＴＣＰ接続を信頼と見なし、その他の場合、前記ＴＣＰ接続を非信頼と見なすことと
   を含み、
   前記ウェブページは、認証情報としてログインおよびパスワードを前記ユーザが入力できるようにするよう構成され、前記分析デバイスは、前記入力されたログインおよびパスワードを事前に記憶されたログインおよびパスワードと比較するか、または
   前記ウェブページは、ＣＡＰＴＣＨＡ画像を表示し、前記ユーザが文字列を入力できるようにするよう構成され、前記分析デバイスは、前記入力された文字列を前記表示されたＣＡＰＴＣＨＡ画像に対応する予め定義される文字と比較し、
   前記ウェブページは、前記検出されたＨＴＴＰ要求メッセージに適合するものとして前記分析デバイスによって決定されるプロファイルのセットの中からプロファイルを前記ユーザが選択できるようにするよう更に構成され、
   各プロファイルは、
   前記シグネチャに適合する各ＨＴＴＰ要求メッセージに存在すると予期されるＨＴＴＰ必須ヘッダのリストと、
   前記シグネチャに適合する各ＨＴＴＰ要求メッセージに存在すると予期されるＨＴＴＰ任意選択的ヘッダのリストと、
   前記シグネチャに適合する各ＨＴＴＰ要求メッセージに存在する特定の値を有するＨＴＴＰ必須ヘッダのリストと、
   前記ＨＴＴＰ必須ヘッダが前記検出されたＨＴＴＰ要求メッセージに現れるシーケンスを表す情報と
   を含む
   ことを特徴とする、方法。
2. 前記ＴＣＰ接続が、前記認証手順に続き非信頼接続として分類される場合、
   前記方法は、
   前記ＨＴＴＰセッションの前記シグネチャを前記シグネチャデータベースに追加することであって、前記ＨＴＴＰセッションの前記シグネチャは、前記シグネチャデータベース内で、非信頼ＨＴＴＰクライアントアプリケーションを表す、追加すること
   を更に含むことを特徴とする、請求項１に記載の方法。
3. 前記シグネチャデータベースに記憶される各シグネチャには、前記シグネチャが信頼ＴＣＰ接続に対応するか、または非信頼ＴＣＰ接続に対応するかを表す第１の安全性インジケータが関連付けられることを特徴とする、請求項２に記載の方法。
4. 前記ＨＴＴＰセッションの前記シグネチャは、
   前記検出されたＨＴＴＰ要求メッセージに存在するＨＴＴＰ必須ヘッダを表す情報と、
   前記検出されたＨＴＴＰ要求メッセージに存在するＨＴＴＰ任意選択的ヘッダを表す情報と、
   前記ＨＴＴＰ必須ヘッダが前記検出されたＨＴＴＰ要求メッセージに現れるシーケンスを表す情報と、
   前記検出されたＨＴＴＰ要求メッセージに存在する前記ＨＴＴＰ必須ヘッダの予め定義されるフィールドに含まれる値を表す情報と
   を含むことを特徴とする、請求項１〜３のいずれか一項に記載の方法。
5. 前記シグネチャデータベースに記憶される前記シグネチャには、少なくとも１つのＩＰアドレスのセットが関連付けられ、
   前記方法は、
   前記ＨＴＴＰセッションの前記シグネチャを前記シグネチャデータベースに追加する際、前記ＨＴＴＰセッションの前記シグネチャに、前記検出されたＨＴＴＰ要求メッセージを発したＩＰソースアドレスを関連付けることと、
   前記ＨＴＴＰセッションの前記シグネチャを前記シグネチャデータベースに事前に記憶された前記シグネチャと比較する際、前記ＩＰソースアドレスに、前記シグネチャデータベースに事前に記憶された任意のシグネチャが関連付けられているか否かをチェックすることと、
   前記シグネチャデータベース内のシグネチャに前記ＩＰソースアドレスが関連付けられていない場合、前記ＨＴＴＰセッションの前記シグネチャが前記シグネチャデータベース内のいずれのシグネチャにも一致しないと見なすことと
   を含むことを特徴とする、請求項１〜４のいずれか一項に記載の方法。
6. 有効な認証情報が受信される場合、前記分析デバイスは、前記選択されたプロファイルおよび前記検出されたＨＴＴＰ要求メッセージのヘッダから前記ＨＴＴＰセッションの前記シグネチャを特定することを特徴とする、請求項１から５のいずれか一項に記載の方法。
7. 前記方法は、
   前記検出されたＨＴＴＰ要求メッセージに関連付けられたＩＰ宛先アドレスを表す情報を取得することと、
   前記シグネチャに基づいて前記ＴＣＰ接続を分類しようとする前に、前記ＩＰ宛先アドレスに基づいて前記ＴＣＰ接続を信頼ＴＣＰ接続または非信頼ＴＣＰ接続として分類しようとすることと
   を含むことを特徴とする、請求項１〜６のいずれか一項に記載の方法。
8. 前記方法は、
   前記ＩＰ宛先アドレスをＩＰアドレスデータベースに事前に記憶されたＩＰアドレスと比較することを含み、
   前記ＩＰアドレスデータベースに記憶される各ＩＰアドレスには、前記ＩＰアドレスが信頼デバイスに対応するか、または非信頼デバイスに対応するかを表す第２の安全性インジケータが関連付けられ、
   各ＴＣＰ接続は、信頼宛先デバイスが信頼として見なされることを暗に示し、各ＴＣＰ接続は、非信頼宛先デバイスが非信頼として見なされることを暗に示す
   ことを特徴とする、請求項７に記載の方法。
9. 前記ＩＰアドレスデータベースを埋めるために、
   前記方法は、
   ＵＤＰデータグラムを受信することと、
   前記受信したＵＤＰデータグラム内のＤＮＳサーバ応答を検出することと、
   前記検出されたＤＮＳサーバ応答から、ＩＰアドレスとドメイン名情報との一致の情報を取得することと、
   前記ドメイン名情報がドメイン名データベースに存在するか否かをチェックすることであって、前記ドメイン名データベースは、前記ドメイン名が信頼であるか、または非信頼であるかを表す第３の安全性インジケータが関連付けられたドメイン名を含む、チェックすることと、
   前記ドメイン名情報が前記ドメイン名データベースに存在する場合、前記ＩＰアドレスデータベースに、前記第３の安全性インジケータに関連付けて、前記ドメイン名情報に一致する前記ＩＰアドレスを追加することと
   を含むことを特徴とする、請求項８に記載の方法。
10. 前記方法は、
    前記検出されたＨＴＴＰ要求メッセージのヘッダから、前記ＨＴＴＰ要求メッセージが参照するＵＲＬを表す情報を取得することと、
    前記シグネチャに基づいて前記ＴＣＰ接続を分類しようとする前に、前記ＵＲＬに基づいて前記ＴＣＰ接続を信頼ＴＣＰ接続または非信頼ＴＣＰ接続として分類しようとすることと
    を含むことを特徴とする、請求項１〜９のいずれか一項に記載の方法。
11. 前記方法は、
    前記ＵＲＬをＵＲＬデータベースに事前に記憶されたＵＲＬと比較することを含み、
    前記ＵＲＬデータベースに記憶された各ＵＲＬには、前記ＵＲＬが信頼デバイスに対応するか、または非信頼デバイスに対応するかを表す第４の安全性インジケータが関連付けられ、
    信頼ＵＲＬを参照するＨＴＴＰ要求メッセージを運ぶ各ＴＣＰ接続は、信頼として見なされ、各ＴＣＰ接続は、非信頼ＵＲＬが非信頼として見なされることを暗に示す
    ことを特徴とする、請求項１０に記載の方法。
12. 信頼ＴＣＰ接続または非信頼ＴＣＰ接続としてＨＴＴＰトラフィックを搬送するＴＣＰ接続を分類するデバイスであって、
    前記ＴＣＰ接続によって搬送される前記ＨＴＴＰトラフィック内のＨＴＴＰセッションのＨＴＴＰ要求メッセージを検出する手段と、
    前記検出されたＨＴＴＰ要求メッセージのヘッダから、前記ＨＴＴＰセッションのシグネチャを構築するための情報を取得する手段と、
    前記ＨＴＴＰセッションの前記シグネチャを、前記分析デバイスによって事前にシグネチャデータベースに記憶されたシグネチャと比較する手段と、
    前記ＨＴＴＰセッションの前記シグネチャが、前記シグネチャデータベースに前記分析デバイスによって事前に記憶され、信頼ＨＴＴＰクライアントアプリケーションを表すシグネチャに一致する場合、前記ＴＣＰ接続を信頼接続として分類する手段と、
    前記ＨＴＴＰセッションの前記シグネチャが、前記シグネチャデータベースに前記分析デバイスによって事前に記憶されたいずれのシグネチャにも一致しない場合、認証手順を実行する手段であって、前記認証手順は、認証データを提供するようにユーザに要求する、実行する手段と、
    有効な認証データが前記ユーザによって提供される場合、前記ＨＴＴＰセッションの前記シグネチャを前記シグネチャデータベースに追加し、前記ＨＴＴＰセッションの前記シグネチャは、前記シグネチャデータベース内で信頼ＨＴＴＰクライアントアプリケーションを表し、前記ＴＣＰ接続を信頼接続として分類する手段と、
    有効な認証データが前記ユーザによって提供されない場合、前記ＴＣＰ接続を非信頼接続として分類する手段と
    を備え、
    前記検出されたＨＴＴＰ要求メッセージを発したデバイスに応答を送信することであって、前記応答は、前記検出されたＨＴＴＰ要求メッセージを発した前記デバイスを別のＵＲＬにリダイレクトする、送信する手段と、
    前記検出されたＨＴＴＰ要求メッセージを発した前記デバイスから、前記別のＵＲＬを参照する別のＨＴＴＰ要求メッセージを受信する手段と、
    前記別のＨＴＴＰ要求メッセージに応答して、前記ユーザが認証情報を入力することができるウェブページを送信する手段と、
    有効な認証情報が受信される場合、前記ＴＣＰ接続を信頼と見なし、その他の場合、前記ＴＣＰ接続を非信頼と見なす手段と
    を含み、
    前記ウェブページは、認証情報としてログインおよびパスワードを前記ユーザが入力できるようにするよう構成され、前記分析デバイスは、前記入力されたログインおよびパスワードを事前に記憶されたログインおよびパスワードと比較するか、または
    前記ウェブページは、ＣＡＰＴＣＨＡ画像を表示し、前記ユーザが文字列を入力できるようにするよう構成され、前記分析デバイスは、前記入力された文字列を前記表示されたＣＡＰＴＣＨＡ画像に対応する予め定義される文字と比較し、
    前記ウェブページは、前記検出されたＨＴＴＰ要求メッセージに適合するものとして前記分析デバイスによって決定されるプロファイルのセットの中からプロファイルを前記ユーザが選択できるようにするよう更に構成され、
    各プロファイルは、
    前記シグネチャに適合する各ＨＴＴＰ要求メッセージに存在すると予期されるＨＴＴＰ必須ヘッダのリストと、
    前記シグネチャに適合する各ＨＴＴＰ要求メッセージに存在すると予期されるＨＴＴＰ任意選択的ヘッダのリストと、
    前記シグネチャに適合する各ＨＴＴＰ要求メッセージに存在する特定の値を有するＨＴＴＰ必須ヘッダのリストと、
    前記ＨＴＴＰ必須ヘッダが前記検出されたＨＴＴＰ要求メッセージに現れるシーケンスを表す情報と
    を含む
    ことを特徴とする、デバイス。
13. プログラマブルデバイスによって実行されたときに請求項１〜１１のいずれか一項に記載の方法を実施するために前記プログラマブルデバイスにおいてロード可能なプログラムコード命令を含むコンピュータプログラム。
14. プログラマブルデバイスによって実行されたときに請求項１〜１１のいずれか一項に記載の方法を実施するために前記プログラマブルデバイスにおいてロード可能なプログラムコード命令を含むコンピュータプログラムを記憶している情報記憶手段。

Images