JP4688420B2 - 電子セキュリティを強化するシステムおよび方法 - Google Patents

Description

(関連出願の相互参照)
本出願は２００３年２月７日に出願された米国特許出願第１０／３６１，０９１号および１０／３６１，０６７号、および全て２００２年３月８日に出願された米国特許出願第１０／０９３，５５３号、１０／０９４，２１１号、および１０／０９４，２６６号に対する優先権を主張し、それらの内容を参照によって本明細書に組み込む。

(背景技術)
本発明は電子通信に関連するセキュリティを強化するシステムおよび方法に対するものである。より具体的には、本発明は、それに限定されるものではないが、通信ネットワークを経て送信される電子通信に関連するセキュリティ・リスクを査定するためのコンピュータ・ベースのシステムおよび方法に関するものである。さらに、本発明はある実施形態では、通信ネットワークを経て送信される電子通信に関連するセキュリティ・リスクを査定し、且つメッセージ・システムに対する脅威の範囲に応答するためのコンピュータ・ベースのシステムおよび方法に関するものである。

インターネットは接続されたコンピュータ・ネットワークのグローバルなネットワークである。ここ数年来、インターネットは膨大に成長してきた。膨大な数のコンピュータがインターネット上で多様な形式の情報を提供している。インテーネットに接続されたコンピュータを持っていれば潜在的には誰でもこの膨大な情報プールを利用できる。

インターネットを入手できる情報には、ＳＭＴＰ（簡易メール転送プロトコル）、ＰＯＰ３（ポストオフィス・プロトコル）、ＧＯＰＨＥＲ（ＲＦＣ１４３６）、ＷＡＩＳ、ＨＴＴＰ（ハイパーテキスト転送プロトコル、ＲＦＣ２６１６）およびＦＴＰ（ファイル転送プロトコル、ＲＦＣ１１２３）のような多様な種類のアプリケーション層情報サーバーを介して入手可能な情報が含まれる。

インターネットを経て情報を提供する最も普及している方法はワールドワイドウエブ（Ｗｅｂ）を介した方法である。Ｗｅｂはインターネットに接続されたコンピュータのサブセットから構成されている。このサブセット内のコンピュータはハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバー（Ｗｅｂサーバー）を実行する。例えば拡張フレームワーク（ＲＦＣ２７７４）およびユーザー間認証（ＲＦＣ２６１７）を含め、ＨＴＴＰへの幾つかの拡張および修正が提案されている。インターネット上の情報は統一資源識別子（ＵＲＩ、ＲＦＣ２３９６）を介してアクセス可能である。ＵＲＩはインターネット上の特定の情報部分のロケーションを一意的に特定する。ＵＲＩは典型的には幾つかの構成要素から構成される。第一の構成要素は典型的には情報のアドレス部分がアクセスされるプロトコル（例えばＨＴＴＰ、ＧＯＰＨＥＲなど）を指定する。この第一の構成要素はコロン（‘：’）によって残りのＵＲＩから分離されている。残りのＵＲＩはプロトコルの構成要素に依存する。典型的には、残りのＵＲＩは名前、またはＩＰ名、ならびに指定されたコンピュータ上のリソースのロケーションのさらに特定された呼称によってインターネット上のコンピュータを指定する。例えば、ＨＴＴＰリソース用の典型的なＵＲＩには、
ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ｄｉｒ２／ｒｅｓｏｕｒｃｅ．ｈｔｍ
があるだろう。ここでｈｔｔｐはプロトコルであり、ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍは指定されたコンピュータであり、ｄｉｒ２／ｒｅｓｏｕｒｃｅ．ｈｔｍは指定されたコンピュータ上のリソースのロケーションである。ＵＲＩという用語はＲＦＣ２１４１にしたがって定義されたＵＲＮを含む統一資源名（ＵＲＮ）を含む。

Ｗｅｂページの形式のＷｅｂサーバー・ホスト情報；ホスト・サーバーおよびホスト情報は全体としてＷｅｂサイトと呼ばれる。その他のエンコードには拡張可能なマークアップ言語（ＸＭＬ）またはＸＨＴＭＬを利用しているものもあるが、相当数のＷｅｂページはハイパーテキスト・マークアップ言語（ＨＴＭＬ）を利用してエンコードされる。これらの言語の公刊された規格は参照によって本明細書に組み込まれている。このような規格はワールドワイドウエブのコンソーシアムおよびそのＷｅｂサイト（ｈｔｔｐ：／／ｗｗｗ．ｗ３ｃ．ｏｒｇ）から入手できる。これらの書式化言語内のＷｅｂページは同じＷｅｂサイト、または別のＷｅｂサイト上の別のＷｅｂページへのリンクを含んでいてもよい。当業者には知られているように、ＷｅｂページはＷｅｂクライアントに送信される前に、書式化されたページに多様な要素を組み込むことによってサーバーがダイナミックに作成できる。Ｗｅｂサーバー、および他の種類の情報サーバーはインターネットのクライアントからの情報要求を待機する。

インターネットに接続されたコンピュータのユーザーがこの情報にアクセスできるようにするクライアント・ソフトウエアが進化を遂げている。ネットスケープのナビゲータ、およびマイクロソフトのインターネット・エクスプローラのような高度なクライアントによって、ユーザーは統一クライアント環境での多様な情報サーバーを介して提供されるソフトウエアにアクセスできる。典型的には、このようなクライアント・ソフトウエアはブラウザ・ソフトウエアと呼ばれる。

電子メール（ｅ−メール）はインターネットを利用してもう１つの広く普及したアプリケーションである。前記のＳＭＴＰおよびＰＯＰ３／ＭＡＰＩ（メッセージ・アプリケーション・プログラミング・インターフェース）を含む多様なプロトコルがｅ−メールの送信、配信、および処理に利用されることが多い。これらのプロトコルはそれぞれ、ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）によって普及された特定のＲＦＣ（コメント・要求）で定義されている。ＳＭＴＰプロトコルはＲＦＣ８２１および８２２で定義され、ＰＯＰ３プロトコルはＲＦＣ１９３９で定義されている。ＭＡＰＩはＰＯＰ３プロトコルを介して提供されるよりも高レベルのメール可能アプリケーション用の通信および組織化を可能にするためにマイクロソフト（マイクロソフト・コーポレーション、ワシントン州レッドモンド）によって開発されたプロトコルである。ＭＡＰＩ用のレファレンス・マニュアルはマイクロソフトのオンライン・レファレンス・マニュアルを経て見出される（ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／）。加えて、ＩＭＡＰプロトコルはｅ−メール・サーバーとクライアントとのさらに高度なインタラクションをサポートするため、ＰＯＰ３の代替として進化したものである。このプロトコルはＲＦＣ２０６０に記載されている。

これらの標準規格の発足以来、ｅ−メールの分野では様々なニーズが発生し、それらが、強化された、または付加的なプロトコルを含むさらなる規格の開発をもたらしてきた。拡張の例は（１）サーバーＳＭＴＰがサポートするサービスの拡張に関してクライアントＳＭＴＰに情報伝達できる手段を定義することによってＳＭＴＰを拡張するためのフレームワークを定義するＲＦＣ１８６９、（２）ＳＭＴＰクライアントが（ａ）ある条件下で配信状態通知（ＤＳＮ）が作成されるべきであること、（ｂ）このよう通知がメッセージのコンテンツを返送すべきか否か、（ｃ）およびＤＳＮの交付先である受信者（単数または複数）およびオリジナル・メッセージが送信されたトランザクションの双方を送信者が特定できるようにする、ＤＳＮと共に返送される追加情報を指定できるようにするＳＭＴＰへの拡張を定義するＲＦＣ１８９１に見出すことができる。

ＨＴＴＰおよびＳＭＴＰの双方とも、公開（暗号化されない）チャネルを経た標準構造の通信メッセージで通信する。送信のセキュリティを強化するため、様々な技術的進展がなされてきた。これらの双方のプロトコル用に２つの暗号化が開発された。すなわちチャネルの暗号化とメッセージの暗号化である。チャネルの暗号化は、確立された暗号化を利用して任意の量のデータを通信可能なセキュア・チャネルを確立する。メッセージの暗号化は個々のメッセージの暗号化を確立し、これらはその後、特定のチャネルを経て送出される。これらのアプローチを組み合わせて、２つのレベルの暗号化、すなわち一方はチャネル・レベル、他方はメッセージ・レベルで暗号化することが可能になる。

ＨＴＴＰ用には、特定形式のメッセージ・レベルの暗号化がＳ−ＨＴＴＰと呼ばれる規格として採用されてきた。このプロトコルの規格はＲＦＣ２６６０に記載されている。ＨＴＴＰはＭＩＭＥ（多目的インターネット・メール拡張）規格（ＲＦＣ）に従ってデータもサポート通信を要求し、これに応答する。これのセキュリティ強化バージョンが実施されており、Ｓ／ＭＩＭＥ（セキュア／多目的インターネット・メール拡張）と呼ばれている。このセキュリティ強化バージョンはさらにメッセージ・レベルの暗号化の手段をも提供する。Ｓ／ＭＩＭＥの具体的な詳細はＲＦＣ２３１１および２６３３に記載されている。Ｓ／ＭＩＭＥの利用をめぐる追加の詳細は、それらに限定されるものではないが、ＲＦＣ２３１２、２６３２、２６３４、２７８５−６、２９８４、３０５８、３１１４、３１２５−６、３１８３、３１８５、３２１１、３２１７−８、３２７４、３２７８、３３６９−７０、および３３９４を含む他の様々なＲＦＣに定義されている（現在のＳ／ＭＩＭＥに関するさらなる詳細はＩＥＴＦのＳ／ＭＩＭＥのチャーター・ホームページであるｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｓｍｉｍｅ−ｃｈａｔｅｒ．ｈｔｍｌ）で見出される。

チャネル・レベルの暗号化用には、ネットスケープ・コミュニケーションズによる初期の開発によってＳＳＬ（セキュア・ソケット層）プロトコルが導入された。バージョン３．０のドキュメンテーションはｈｔｔｐ：／／ｗｐ．ｎｅｔｓｃａｐｅ．ｃｏｍ／ｅｎｇ／ｓｓｌ３／ｓｓｌ−ｔｏｃ．ｈｔｍｌで見出すことができる。このチャネル暗号化メカニズムは一般に利用されており、ＵＲＬはｈｔｔｐ：ではなくｈｔｔｐｓ：を用いてこのプロトコルを利用することを示している。ＳＳＬと後方互換性があるようにしたより新しい技術はＴＬＳ（トランスポート層セキュリティ）である。その完全な説明はＲＦＣ２２４６に記載されている。ＴＬＳをめぐるその他の詳細は、それらに限定されるものではないが、ＲＦＣ２７１２、２８１７−８、および３２６８を含む他のさまざまなＲＦＣで定義されている。（ＴＬＳの現時点での開発のさらなる詳細はＩＥＴＦのＳ／ＭＩＭＥのチャーター・ホームページであるｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｓｍｉｍｅ−ｃｈａｔｅｒ．ｈｔｍｌ）で見出される。

ＳＭＴＰ用には、同様の技術が適用されてきた。メッセージ・レベルの暗号化には様々な形式の公開鍵暗号化技術が利用されてきた。最も広範に利用されている公開鍵の１つはＰＧＰ（プリティグッドプライバシー）と呼ばれる。ＳＭＴＰ配信メッセージと組み合わせてＳ／ＭＩＭＥを利用することもできる。ＨＴＴＰと同様に、チャネル・レベル暗号化メカニズムとしてＳＳＬまたはＴＬＳを利用することも可能である。さらに、チャネル暗号化、および１つ以上のメッセージ暗号化の双方をセキュアＳＭＴＰ配信と組み合わせて利用することもできる。

上記のさまざまな標準規格はあらゆる目的のため参照によって本明細書に組み込まれている。ＲＦＣによって言及されている規格はＩＥＴＦを介して公に利用され、Ｗｅｂサイトから検索できる（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｅｃ．ｈｔｍｌ）。特定されたプロトコルは上記に引用された特定のＲＦＣに限定するものではなく、その拡張および改訂を含めるものである。このような拡張および／または改訂は現在および／または将来のＲＦＣに含めても含めなくてもよい。

インターネットを経たｅ−メールを促進するため、多数のｅ−メール・サーバーおよびクライアント製品が開発されている。ｅ−メール・サーバー・ソフトウエアにはセンドメール・ベースト・サーバー、マイクロソフト交換、ロータス・ノート・サーバーおよびノーベルグループワイズのような製品が含まれる。センドメール・ベースト・サーバーは元来ＵＮＩＸ（登録商標）オペレーティングシステム用に開発されたセンドメール・プログラムに基づく幾つかのサーバーのバリエーションのことである。ユーザーがサーバーからのｅ−メール・メッセージを検索し、閲覧できるようにするため多数のｅ−メール・クライアントが開発されてきた。製品の例にはマイクロソフトのアウトルック、マイクロソフトのアウトルック・エキスプレス、ネットスケープ・メッセンジャー、およびＥｕｄｏｒａが含まれる。加えて、ある種のｅ−メール・サーバーまたはｗｅｂサーバーと連携したｅ−メール・サーバーによってＷｅｂブラウザはＨＴＴＰ規格を利用してｅ−メール・クライアントとしての役割を果たすことができる。

インターネットはより広範に利用されるようになってきたので、企業にとっての新たなリスクも生じている。ハッカーや侵入者によるコンピュータ・セキュリティの侵害、および機密の企業情報を脅かす可能性は極めて現実的で深刻な脅威である。組織はそのネットワークをインターネット攻撃から防護するために下記の技術の一部または全てを実施してきた。

ファイヤウォールは企業ネットワークの周辺で配備されてきた。ファイヤウォールは門番としての役割を果たし、認可されたユーザーだけが会社のネットワークにアクセスすることを許可する。ファイヤウォールはネットワークへのトラフィックを制御する上で重要な役割を果たし、インターネット・セキュリティを備えるための第一歩である。

侵入検知システム（ＩＤＳ）は企業ネットワーク全体を通して配備されている。ファイヤウォールが門番としての役割を果たすのに対して、ＩＤＳはビデオカメラのように動作する。ＩＤＳはネットワーク・トラフィックの不審な活動パターンを監視し、そのような活動が検出されると警報を発する。ＩＤＳは企業内、またはその他のローカル・ネットワーク内の侵入者を特定するために、あなたのネットワークを事前に２４時間監視する。

ファイヤウォールおよびＩＤＳは企業が自らのネットワークを保護し、企業情報資産を防御することを補助してきた。しかし、これらのデバイスの利用が広範にわたっているので、ハッカーは適応化し、現在では標的をネットワークからインターネット・アプリケーションへとシフトしてきている。最も無防備なアプリケーションはウエブおよびｅ−メールのようなインターネットとの直接の“常開”接続を必要とするアプリケーションである。その結果、侵入者はこれらのアプリケーション内のセキュリティ・ホールを標的にした精巧な攻撃に乗り出している。

多くの企業は企業のコンピュータ・ネットワークから出入りするトラフィックの流れを制御する１つの手段としてネットワーク・ファイヤウォールをインストールしてきたが、ｅ−メール・メッセージやＷｅｂ要求および応答のようなインターネット・アプリケーション通信となると、企業は従業員が社内外の誰から（へ）の、またはどこから（へ）の通信をも送受信することを許容している場合が多い。これはトラフィックの流れを可能にするためにファイヤォールのポートまたはホール（典型的にはｅ−メールの場合はポート２５、またＷｅｂの場合はポート８０）を開くことによって行われる。ファイヤウォールはこのポートを経たトラフィックの流れを精査することはない。これは、会社の入口にセキュリティ・ガードを配備してはいるが、サービス要員に見える誰かがビルに入ることができることと同様である。侵入者はサービス要員であると見せかけ、周辺セキュリティを回避し、供給されているインターネット・アプリケーションを損なうことができる。

図１は典型的な従来のサーバー・アクセス・アーキテクチャを示している。企業のローカル・ネットワーク１９０内に多様なコンピュータ・システムが存在する。これらのシステムには典型的には、Ｗｅｂサーバーおよびｅ−メール・サーバーのようなアプリケーション・サーバー１２０、ｅ−メール・リーダーおよびＷｅｂブラウザのようなローカル・クライアント１３０を実行するワークステーション、およびデータベースおよびネットワーク接続ディスクのようなデータ記憶デバイス１１０が含まれる。これらのシステムはイーサーネット１５０のようなローカル通信ネットワークを介して互いに通信する。ローカル通信ネットワークとインターネット１６０との間にはファイヤウォール・システム１４０が存在する。インターネット１６０には多数の外部サーバー１７０と外部クライアント１８０が接続されている。

ローカル・クライアント１３０はローカル通信ネットワークを経てアプリケーション・サーバー１２０および共用データ記憶装置１１０にアクセスすることができる。外部クライアント１８０はインターネット１６０を経て外部アプリケーション・サーバー１７０にアクセスすることができる。ローカル・サーバー１２０またはローカル・クライアント１３０が外部サーバー１７０へのアクセスを要求するか、または外部クライアント１８０または外部サーバー１７０がローカル・サーバー１２０へのアクセスを要求する場合、所定のアプリケーション・サーバー用の適宜のプロトコル内の電子通信がファイヤウォール・システム１４０の“常開”ポートを通って流れる。

そこでセキュリティのリスクは止まらない。メール・サーバーを乗っ取った後は、侵入者にとってはこれを他のビジネス・サーバーを脅かし、重要なビジネス情報を盗むためのランチパッドとして利用することは比較的容易である。この情報には財務データ、販売プロジェクト、顧客パイプライン、契約交渉、法的案件、およびオペレーション・ドキュメントが含まれる。ハッカーによるサーバーに対するこの種類の攻撃によって、ビジネスに計り知れない、また修復不能な損失が生ずることがある。

１９８０年代、主としてフロッピー（登録商標）ディスクによってウイルスが蔓延した。今日の相互に接続された世界では、ｅ−メールのようなアプリケーションは容易に、かつ広範に蔓延するウイルスの媒体の役割を果たす。“Ｉ ｌｏｖｅ ｙｏｕ”のようなウイルスは大量増殖のために分散サービス妨害（ＤＤｏＳ）のアタッカーによって開発された技術を利用している。“Ｉ ｌｏｖｅ ｙｏｕ”ウイルスを受信すると、受信者のマイクロソフト・アウトルックはウイルスに感染されたｅ−メールをアウトルックのアドレス帳にある全員に送信する。“Ｉ ｌｏｖｅ ｙｏｕ”ウイルスはそれが放出されたから短期間で１００万台ものコンピュータを感染させた。コード・レッドのようなトロイの木馬はそれを蔓延させるために上記と同じ技術を利用している。ウイルスおよびトロイが原因で、ダウンタイムおよび極めて重要なデータの損失により生産性が大幅に低下することがある。

ニムダ・ウオームはｅ−メールとウエブ・アプリケーションの双方を同時に攻撃する。これは感染したｅ−メール・メッセージを作成、送信することによって自己増殖し、ネットワークを介してコンピュータを感染させ、ウエブ・メールを提供するために交換メール・サーバー上で展開されている無防備なマイクロソフトＩＩＳＷｅｂサーバーを攻撃する。

ほとんどのｅ−メールおよびＷｅｂ要求および応答は現在ではプレーン・テキストで送信され、ポストカードのように露出されている。それにはｅ−メール・メッセージ、そのヘッダ、および添付メールが含まれ、またはＷｅｂのコンテキストではユーザー名およびパスワードおよび／またはＨＴＴＰ要求におけるクッキー情報が含まれる。加えて、ｅ−メール・メッセージを送信または受信するためにインターネット・サービスプロバイダ（ＩＳＰ）にダイアルすると、ユーザーＩＤおよびパスワードもプレーン・テキストで送信され、これはスヌープ（監視）され、コピーされ、改ざんされる可能性がある。これは痕跡を残さずに実行可能であり、メッセージが損なわれたかを知ることが不可能になる。

インターネットは一層広範に利用されるようになってきたので、ユーザーにとっても新たなトラブルが生じるようになった。具体的には、個々のユーザーが受信した“スパム”（迷惑メール）の量は最近になって激烈に増加してきた。本明細書で用いるスパムとは、受信者が頼んでも望んでもいない何らかの通信の受信のことである。

下記はインターネット・アプリケーションによって誘発されるその他のセキュリティ・リスクである。

・ｅ−メールスパミングが企業資源を消耗刺せ、生産性に打撃を与える。その上、スパム送信者は無認可のｅ−メール中継用に企業独自のメール・サーバーを利用し、そのメッセージがあたかもその企業から着信したように見せかける。

・不適切なメッセージおよびＷｅｂページの送信および受信のようなｅ−メールおよびＷｅｂの悪用は企業にとってマイナス材料を生ずる。企業は従業員が送信または受信したｅ−メールによるセクシャルハラスメントまたは誹謗中傷の訴訟に直面することが増えている。

・医療保険の携行性と責任に関する法律（ＨＩＰＰＡＡ）、および金融制度改革法（金融機関を規制）のような法規の基準が、ｅ−メール、Ｗｅｂページ、およびＨＴＴＰ要求を含むｅ−メールおよび／またはＷｅｂサーバーまたは通信に機密の患者またはクライアント情報が曝されることがある企業にとってマイナス材料を生ずる。

“常開”ポートを利用して、ハッカーは適当なインターネット・アプリケーション・サーバーに簡単に到達し、その無防備さを食い物にし、サーバーを乗っ取る。それによってハッカーは、攻撃を受け易い機密情報を含むことが多い、サーバーが利用できる情報に容易にアクセスできる。本発明によるシステムおよび方法は、“常開”接続を必要とするこのようなインターネット・アプリケーションに含まれる通信に対して強化されたセキュリティを提供するものである。

今日利用されているアンチスパム・システムには着信メッセージが全てスパムを排除するためにフィルタにかけられるフェール・オープン・システムが含まれる。これらのシステムでは、メッセージはある形式の試験がそうであることを実証するまではスパムではないものと見なされる。メッセージは識別技術に基づいてスパムであると判定される。このようなシステムのオペレータは誤ってスパムであると分類される適正なメッセージの数を減らすための努力に相当のリソースを投資し続ける。分類ミスの不利益は相当なものであるため、ほとんどのシステムはメッセージをスパムであると分類しにくいように設計されている。

このようなアプローチの１つはｅ−メールを求めているユーザーをリストに明示することをユーザーに対して要求する。このようなリストはある種の“ホワイトリスト”である。このようなホワイトリストを作成するには現在２つのアプローチがある。デスクトップ環境では、最終ユーザーはアドレス帳をホワイトリストとしてインポートすることができる。このアプローチは、組織のゲートウエイのようなより中央のロケーションで動作される場合には重荷になることがある。したがって、組織によっては必要に応じてわずかなエントリしかホワイトリストには追加しないものもある。しかし、この場合はホワイトリスト作成の完全な効果は達成されない。本発明は、最終ユーザーまたは管理者による手動的な努力への要求を少なくしつつ、ホワイトリスト作成のより効率的な解決方法を可能にするシステムを含めることによって、上記のシステムを改良するものである。本発明によってさらに、送信者情報を認証することによってホワイトリスト・システムを強化することが可能になる。

今日利用されている別のシステムは、送信者が適法性を証明しなければならないフェール・クローズド・システムである。この種類のシステムの一般的な例は、チャレンジ−レスポンスを利用している。このようなシステムは未知の送信者からのメッセージは全て遮断し、それ自体が送信者に確認メッセージを送信する。送信者はこれに応答してそれが適正な送信者であることを立証しなければならない。送信者が応答すると、その送信者はホワイトリストに加えられる。しかし、スパム送信者は確認メッセージに応答するツールを作成することができる。ある種の確認メッセージは、人が応答を送信することを要求する努力においてさらに進歩している。本発明はこれらのシステムを改良する。本発明は送信者の確認に依存するのではなく、誰がホワイトリストに加えられるべきかを判断するためにユーザーによって提供された情報を参照することができる。本発明によるシステムおよび装置は電子通信の自動処理の精度を強化する。

開示内容が参照によって本発明に組み込まれている、ブライトライトテクノロジー社に授与された米国特許明細書第６，０５２，７０９号は、ルールを作成し、サーバーに送信することが可能であるようにスパム・メッセージを収集するシステムを開示している。開示されているシステムはデータ収集工程と、ルール作成工程と、クライアントにルールを配信する工程とを含んでいる。開示されたシステムはスパム・メッセージ用の特定のデータ収集方法に対するものである。入力されたデータに基づいてルールを作成するシステムまたは方法は開示されていない。これはさらに、ルールを作成する体系的なアプローチも開示していない。その上、開示されているシステムはスパムの脅威に限定されており、１種類の入力しか許容しない。本発明の脅威管理センターは、それらに限定されるものではないがスパム、ウイルス、ウォーム、トロイ、侵入の企てなどを含むあらゆるメッセージへの脅威に対して動作する。本発明の脅威管理センターはさらに、ルール作成プロセスへの新規のアプローチも含んでいる。加えて、本発明はさらに汎用で有用なデータ収集のアプローチを提供することによって先行技術を改良する。本発明のデータ収集システムにはルール作成プロセスが利用できるデータへの入力を処理するモジュールを含んでいる。本発明はさらに、ルール作成プロセスへの入力として、アプリケーション層セキュリティ・サーバーからのフィードバックを利用することもできる。

開示内容が参照によって本発明に組み込まれている米国特許出願第１０／１５４，１３７号（公刊番号２００２／０１９９０９５号）は、メッセージ・フィルタリングのためのシステムを開示している。開示されているシステムによって、スパム・メッセージはシステムのユーザーによってデータベースへと送出されることができる。これに対して、本発明のシステムおよび方法はユーザーに依存せず、むしろメッセージ送信セキュリティ・システム（単数または複数）が識別技術を利用して自動的にスパムを判定し、その後、結果をデータベースに送出することができる。本発明のシステムはシステムを保持するために、判明しているスパム・メッセージ、ならびにユーザーによって送出された分類ミスのメッセージをデータベースに加えることができる。公知のシステムではメッセージ全体をデータベースに送出する必要がある。本発明では、個々のメッセージ、またはアプリケーション層セキュリティ・システムはスパン・メッセージ、脅威メッセージ、および／または非スパム／非脅威メッセージから有意の特徴を抽出し、関連する特徴だけをデータベースに送ることができる。

開示内容が参照本によって本明細書に組み込まれている米国特許第６，１６１，１３０号は“ジャンク（迷惑）”ｅ−メールを検出する技術を開示している。開示されているシステムはスパムに対してのみ動作し、全種類のメッセージ・セキュリティへの脅威に対しては動作しない。開示されているシステムのための入力は限定されたスパムおよび非スパムｅ−メールである。この特許はメッセージ中のトークンのようなテキスト分析をベースにした機能を開示している。この特許は“あらかじめ規定された手作りの区別”を開示しているが、それらが何であり、どのようにして作成できるかは開示していない。本発明のシステムはテキスト分析だけではなくメッセージの他の特徴に基づく分類も可能である。加えて、本発明のシステムはヘキスト・ベースではない特徴を抽出するための全自動機能を含むことができる。

さらに、脅威情報のピア・ツー・ピア・システムを提供するための公知のセキュリティ・システムが開発されている。このようなシステムは典型的には信頼できないピアのリング向けに開発されたものなので、ピア間の信用管理に対処するものである。さらに、現在のピア・ツー・ピア・システムは中央エンティティを有していない。本発明のシステムは信頼されているピアの集合間で動作する。したがって、本発明は信用管理を取り扱う必要はない。さらに、集中化された脅威管理システムは、ピア・ツー・ピア式に通信する複数の信頼できるアプリケーション層セキュリティ・システム間で脅威情報をコーディネートする。したがって、脅威通知システムはよりリアルタイムのデータ交換を処理することができる。それによって分散ＩＤＳ（侵入検出システム）をよりスケーラブルにできる。

さらに、現行のシステムは侵入警報しか交換しない。これらのシステムはこれらが把握している攻撃を互いに通知できるだけである。根底にある検出システムは誤用または異常の検出が可能であるものの、交換されるデータは検出された攻撃データだけである。本発明のシステムはトラフィック・パターン、ならびに特定の脅威情報に関するより包括的な情報を配信する。限定するものではないが一例として、異常の検出が利用された場合、本発明のシステムは攻撃があることを示すため、統計を待つのではなく、基礎をなす統計を交換することができる。高官される統計にはある攻撃の周波数に関する情報を含めることができる。したがって、他のシステムがある種の攻撃の形跡を既に有している場合でも、本発明のシステムはそれらのシステムにその攻撃の発生を通知する。さらに、ピア間でトラフィック・パターンを交換可能であり、その情報はトラフィック・パターンのグローバルな視野を推測するために他のピアによってさらに処理されることができる。この情報交換は各ノードがネットワーク・トポロジーのグローバルな視野を推測できるルーティング・プロトコルと同類であってよい。

(発明の要旨)
本発明は電子通信のセキュリティ配信のシステムおよび方法に対するものである。典型的なアーキテクチャは下記の構成要素の１つ以上を含むことができる。１）脅威情報を収集し、メッセージング・セキュリティ・システム用のルールおよび／または方針を作成することができる集中脅威管理センター、２）メッセージング・セキュリティ・システム間で動作可能なピア・ツー・ピアベースのメッセージング通知システム、および３）ソースへと向かう経路上でシステムに通知を送信することによって、ソースのできるだけ近くで通信を遮断する階層的メッセージング・プッシュバック・システム。

セキュア電子通信配信システム、またはセキュア配信を含む多様な機能をサポートする全体的な環境としての本発明の好適な実施形態は、システム・データ・ストア（ＳＤＳ）と、システム・プロセッサおよび電子通信がそれを介して送受信される１つ以上の通信ネットワークへの１つ以上のインターフェースとを含んでいる。ＳＤＳは所望のシステム機能を提供するために必要なデータを記憶し、これには例えば、受信した通信、このような通信に関連するデータ、判明しているセキュリティ・リスクに関する情報、セキュア配信機構に関する構成データ、受信者セキュア配信基本設定（ｐｒｅｆｅｒｅｎｃｅｓ）、１つ以上のアプリケーション用の通信に対する企業の方針（例えば企業のｅ−メール方針、Ｗｅｂアクセスのガイドライン、メッセージ質問パラメータ、およびホワイトリスト）に関する情報、および特定のセキュリティ・リスク、状況、または異常性の識別に対する所定の応答が含まれていてもよい。

ＳＤＳは多様な種類の情報を記憶するための複数の物理的および／または論理的データ・ストアを含んでいてもよい。データ記憶および検索機能はシステム・プロセッサまたはデータ・ストアに関連するデータ記憶プロセッサのいずれかによって提供されればよい。システム・プロセッサはいずれかの適宜の通信チャネル（単数または複数）を介してＳＤＳと通信する。システム・プロセッサは同一の、または異なる通信チャネル（単数または複数）を介して１つ以上のインターフェースと通信する。システム・プロセッサは電子通信の受信、送信、質問、分析および／またはその他の機能性を提供する１つ以上の処理要素を含んでいてもよい。

脅威管理センターでは、ＳＤＳはさらに１組以上の脅威管理目標、および／または１組以上のテスト・データを含んでいてもよい。したがって、好適な１つの脅威管理方法は、ある実施形態では上記に概説し、以下により詳細に記載する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。脅威情報は１つ以上のソースから受信される。このようなソースは外部セキュリティ・データベース、および１つ以上のアプリケーションおよび／またはネットワーク層セキュリティ・システムからの脅威情報を含むことができる。受信された脅威情報は正規の形式へと還元される。還元された脅威情報から特徴が抽出される。これらの特徴は目標のような構成データと組み合わせてルールを作成するために利用される。ある実施形態では、これらのルールは１組以上のテスト・データに対してテストされ、同一の、または異なる目標と比較される。１つ以上のテストで不合格の場合は、許容される誤差範囲内でテストに合格するまでルールが改良される。次にルールは１つ以上のアプリケーション層セキュリティ・システムに伝播される。

１つの好適な脅威プッシュバック方法は、ある実施形態では、上記に概説し、以下により詳細に説明する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。通信が受信される。受信された通信に関連する脅威のプリファイルが作成される。ある場合には、この作成は受信された通信に１つ以上のテストを実施することによって行われ、１つ以上のテストは各々、受信された通信を特定のセキュリティ・リスクに関して評価する。別の場合は、備えられたインターフェースを介した脅威プロファイルの手動入力が脅威プロファイルを作成する役割を果たす。脅威プロファイルは構成情報と比較される。標準的には、構成情報は対象となる脅威の種類、およびこれに関連する重みを含むことができる。ある実施形態では、脅威プロファイルから脅威の数値を計算し、その脅威値が所定の脅威条件を満たすか否かを判定することによって比較が行われる。比較の結果、受信された通信が脅威を表すことが示されると、受信された通信のバックパス内の１つ以上のアドレスが識別され、記憶された脅威プロファイルに基づく情報が出力される。

ある実施形態では、バックパスに沿った識別された情報は脅威情報が伝播される前に認証される。別の実施形態では、１種類以上の脅威に関する構成情報を構築できるようにインターフェースを備えてもよく、構成情報は対象となる脅威の種類と、これに関する重みとを含んでいる。

したがって、ホワイトリストを利用する好適な方法の１つは、ある実施形態では、上記に概説し、以下により詳細に説明する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。ある実施形態では、アプリケーション・サーバーに向けられ、またはそこから発される電子通信が受信される。電子通信のソースは適宜の任意の内部または外部クライアントでもよく、または適宜の任意の内部または外部アプリケーション・サーバーでもよい。受信された通信を特定のセキュリティ・リスクに関して評価するため、受信された電子通信に対して１つ以上のテストが実施される。このテストに基づいて、受信された電子通信に関連するリスク・プロファイルが記憶される。記憶されたリスク・プロファイルは以前に受信された電子通信から累積されたデータと比較されて、受信された電子通信が異常であるか否かが判定される。受信された電子通信が異常であると判定され場合は、異常表示信号が出力される。出力された異常表示信号は、ある実施形態では、適宜の通知機構（例えば書面、ｅ−メールなど）によってアプリケーション・サーバーの管理者に対して検出された異常を通知してもよく、またはアプリケーション・サーバーの全面的な、または部分的なシャットダウンのようなある種の修正手段をトリガしてもよい（例えば、特定のソースからの全て通信へのアクセスの拒絶）。

ある実施形態は、記憶されたリスク・プリファイルに基づいて通信情報のためのサポートを、さらに別のセキュリティ装置（単数または複数）に対する脅威通知システムに提供できる。限定されるものではないが、このようなセキュリティ装置には脅威管理センター、およびその他のアプリケーション層セキュリティ・システムを含めることができる。このような情報の通信はいずれかの異常表示信号の代用になり、またはそれに加えることができる。ある実施形態では、異常の検出が行われる必要もなく、異常表示信号が出力される必要もない。

ある実施形態では、ｅ−メール・サーバーに向けられ、またはそこから発される電子通信が受信される。受信された電子通信の送信者アドレスと、１つ以上のホワイトリストに含まれるアドレスとを比較するため、受信された電子通信に１つ以上のテストが実施される。

ある実施形態はさらに、受信された電子通信をテストする特定のアプローチをサポートすることもでき、これはネットワーク・レベルのセキュリティおよび侵入の検出に適用してもよい。このような実施形態では、受信された各通信は複数個の質問エンジンによって質問され、このような各々の質問エンジンは特定のセキュリティ・リスク向けに通信をテストするように設計された特殊な種類のエンジンである。受信された各通信は異なる種類の一連の質問エンジンによって質問される。受信された通信で利用される質問エンジンの種類の順番と選択は、ある実施形態では構成可能であるが、別の実施形態では順番と選択が固定されることもある。

各質問エンジンには、特定の質問エンジンによって評価される通信向けのインデックス待ち行列（ｑｕｅｕｅ ｏｆ ｉｎｄｉｃｅｓ）が関連している。通信が受信されると、これは記憶され、インデックスが割り当てられる。受信された通信用のインデックスは、質問エンジンの順番によって決定される特定の種類の質問に関連する待ち行列内に配置されている。割り当てられた待ち行列に関連する質問エンジンによる受信された通信の査定が完了すると、質問エンジンの順番によって決定される次の種類の質問エンジンに関連する新たな待ち行列内にインデックスが割り当てられる。割り当て工程は、受信された通信が質問エンジンの選択によって決定された各種の質問エンジンによって査定され終わるまで継続される。その通信が各種の質問エンジンを首尾よくパスすると、通信は適宜の宛先に送出される。ある実施形態では、通信がいずれかの特定のエンジンをパスしないと、警告表示信号が出力されてもよい。このような実施形態の中には、次に通信が不合格の表示尽き、または表示なしで適宜の宛先、アプリケーション管理者および／または双方に送出される実施形態もある。

ある実施形態では、システムはメッセージを宛先に送出するために選択されたセキュア配信機構を利用することができる。このようなセキュア配信は、上記、または下記の質問および／または脅威管理機能のどれをも必要としない独立した自立型システムとして行われることができ、または上記の機能の一部または全部を供給する統合された環境で動作してもよい。

本発明は通信リンクにセキュリティをかけることによって（チャネル層セキュリティ）、または送信データにセキュリティをかけることによって（メッセージ層セキュリティ）セキュア通信サービスを提供することができる。チャネル層セキュリティおよびメッセージ層セキュリティは別個に、または組み合わせて提供されることができる。本発明の幾つかの好適な実施形態は、ＳＳＬまたはＴＬＳを利用してチャネル層セキュリティを提供することができる。本発明の好適な一実施形態は、限定的ではない例として、例えばｅ−メールおよびＷｅｂ要求および応答を含む電子通信を送信および／または受信することが可能である。これに加えて、またその代替として、本発明は適用可能なプロトコルを利用したインスタント・メッセージ、ファイル、ページャ・メッセージおよび音声のような別の形態の電子通信を送信および／または受信することが可能である。

したがって、セキュア配信の１つの好適な方法は、ある実施形態では上記に概説し、以下により詳細に記載する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。ある実施形態では、受信された通信がセキュア配信を要求しているか否かの判定がなされる。このような実施形態のあるものでは、構成されたデフォールトがセキュア配信を要求することがある。別の実施形態では、セキュア配信が想定されているか否かの判定をする必要がない。所定の受信者への通信のセキュア配信が試行される。この試行は利用可能な１つ以上の配信機構群から選択されたセキュア配信機構を利用する。ある実施形態では、最初の試行が失敗すると第二の配信機構が選択され、この第二の機構を介した配信の試みがなされる。このような実施形態のあるものでは、配信が成功するまで、またはるよう可能な機構が使い果たされるまで別の機構によって配信する反復的な試行がなされてもよい。

この待ち行列アプローチを利用したある実施形態では、受信された通信用のインデックスの、特定の種類の質問エンジン用の待ち行列への割り当てには、特定の種類の質問エンジン用の全ての待ち行列への電流負荷の評価が含まれてもよい。閾値の負荷が存在する場合、特定の種類の質問エンジンの新たなインスタンスが、関連するインデックス待ち行列と共に発生することがある。その場合は、受信された通信用のインデックスが前記の質問エンジン・インスタンスに関連する待ち行列に割り当てられてもよい。ある実施形態では、特定の種類の質問エンジンに関連する待ち行列にかかる負荷は、新たに受信された通信に関連するインデックスを待ち行列へと割り当てる前に、新たな質問エンジン・インスタンスに関連する待ち行列を含む待ち行列全体に再分散されてもよい。ある実施形態はさらに、周期的に、または特定の待ち行列が空であると判定された場合のような特定の時点である種の質問エンジン用の待ち行列への負荷を評価し、動作停止閾値になると、その種類の過度の質問インスタンスをシャットダウンし、シャットダウンされたインスタンスに関連するインデックス待ち行列を引き離し、または割り当てを解除（ｄｅａｌｌｏｃａｔｉｎｇ）する。

あるいは、各々の特定種類の固定数の質問エンジンを構成してもよく、その場合はダイナミック・インスタンス生成が生じても生じなくてもよい。ダイナミック・インスタンス生成をサポートしない固定インスタンスの実施形態では、所望の特定の種類の各質問エンジン・インスタンスに関連する待ち行列の負荷の評価、または連続循環を含む任意の適宜のアプローチによって特定の待ち行列への割り当てがなされてもよい。

ある実施形態では、異常の検出は下記のように略述される工程を経て行われてもよい。このような工程では、受信された通信に関連するデータが収集される。データは多様なソース、例えば通信自体から、および通信の送受信の態様から収集できる。データは上記に概説し、以下に詳述する多重の待ち行列質問のような任意の適宜の態様で収集してよい。あるいはデータ収集は、多様なテストが受信された通信に個別的に並行して実施される並行テスト工程から行われてもよい。別の実施形態では、多次元にわたる受信された通信に関連するデータを同時に収集するため、例えばニューロネットワークを介した単一の複合的分析を適用してもよい。

収集されたデータは次に、受信された通信が異常を呈しているか否かを判定するために分析される。この分析は典型的には、以前に受信された通信に関連する集計されたデータによって表される所定期間を経て確立された通信パターンと共に、受信された通信に関連する収集済みデータに基づいて行われる。分析はさらに、規定された、および／または構成可能な異常ルールに基づくものでもよい。ある実施形態では、分析をデータ収集と組み合わせてもよい。例えば、ニューロネットワークが、受信された通信に関連するデータを収集し、これを分析する双方を行うことができよう。

適応通信質問は以前に受信された通信に関連する統合されたデータによって表される、構築された通信パターンを所定期間利用することができる。分析はさらに、規定されたおよび／または構成可能なスパム・ルールに基づいて行うことができる。ある実施形態では、分析をデータ収集と組み合わせることができる。例えば、ニューロ・ネットワークは受信された通信に関連するデータの収集とその分析の双方が可能であろう。

最後に、受信された通信に関して異常が検出されると、表示信号が発生される。発生された信号はアプリケーションの管理者に警告を発してもよく、他の何らかの適切な動作を起動してもよい。ある実施形態では、発生された表示信号は異常の一般化された表示を行ってもよい。別の実施形態では、表示信号は検出された特定の異常（単数または複数）に関する追加データを供給してもよい。後者の実施形態では、信号に起因するどの警告および／またはアクションも追加データに依存することができる。

この実施形態では、受信された通信が１つ以上のホワイトリストにあるか否かを判定するため、信号に誘発されるいずれかの警告および／または動作を分析することができる。分析は典型的には、１つ以上のホワイトリストの参照と共に、受信された通信に関連する収集済みデータに基づいて行われる。ホワイトリストとの一致が見出されない場合は、通信にはあるレベルの質問を受けることができる。ホワイトリストとの一致が見られた場合は、通信はメッセージ質問を迂回するか、別のレベルの質問を受けることができる。好適な一実施形態では、ホワイトリストとの一致が見られた場合は、通信は適応メッセージ質問を受けるか、またはメッセージな質問を受けないことができる。ホワイトリストとの一致が見出されない場合は、メッセージは通常のメッセージ質問を受けることができる。さらに、アウトバウンド通信に基づいてホワイトリストを作成および／または更新することができる。好適な一実施形態では、アウトバウンド通信の宛先アドレスの一部または全部がホワイトリストに加えられる。宛先アドレスが既にホワイトリストにある場合は、宛先アドレスの存在に基づいて、そのあて先に関連する機密値を修正することができる。例えば、利用カウントを保存してもよい。このような利用カウントは絶対的なアドレス利用回数、または所定の期間にわたるアドレス利用回数を反映することができる。

本発明のその他の利点は、一部は以下の説明で開示され、また一部は説明か羅明らかになり、または本発明の実施によって学習できよう。本発明の利点は添付の特許請求の範囲で特に指摘した要素および組み合わせによって実現され、獲得される。これまでの一般的な説明と以下の詳細な説明は例示および説明目的であるに過ぎず、特許請求がなされている本発明を限定するものではないことを理解されたい。

（発明の詳細な説明）
ここで本発明の実施例を詳細に説明する。図を参照すると、図面全体を通して同様の番号は同様の部品を示す。本明細書、およびそれに続く特許請求の範囲を通して用いられる“ａ”、“ａｎ”、および“ｔｈｅ”は文脈上で明らかに別の指図がない限りは複数指示を含む。さらに、本明細書、およびそれに続く特許請求の範囲を通して用いられる“ｉｎ”（中）は文脈上で明らかに別の指図がない限りは“ｉｎ”（中）および“ｏｎ”（上）の意味を含む。最後に、本明細書、およびそれに続く特許請求の範囲を通して用いられる“ａｎｄ（および）”および“ｏｒ（または）”は接続語と離切語の双方を含み、文脈上で明らかに別の指図がない限りは互換的に用いてもよい。

本明細書では範囲は１つの“およその”特定値から、および／または別の“およその”特定値までとして表されてもよい。このような範囲が表現された場合、他の実施形態は１つの特定値からおよび／または別の特定値までを含む。同様に、数値が“約”の先行詞を付して近似値として表される場合は、特定の値が別の実施形態を形成することが理解されよう。さらに、各々の範囲の端点は他の端点との関係で、および他の端点とは関わりなく、双方とも重要であることが理解されよう。
典型的なアクセス環境のアーキテクチャ
図１２は本発明の脅威管理アーキテクチャの様々な態様を利用した１つの環境を通る情報の流れの概観である。メッセージ・セキュリティ・システム（ＭＳＳ）（例えば１２０５）で、トラフィックおよび脅威パターンに基づいて統計が収集される。統計は個々のＭＳＳによってローカルに処理されることができ、または外部プロセッサによって処理されることができる。ＭＳＳはハードウエア・デバイス２１０のようなアプリケーション層セキュリティ・システムの例である。詳細な情報を１つ以上のＭＳＳから脅威管理センター（ＴＭＣ）１２１０へと返信可能である。ある実施形態では、複数個のＭＳＳがピア・ツー・ピア・システム１２１５として動作できる。好適な実施形態では、収集された情報および／または計算された統計をＭＳＳ１２０５から脅威通知およびプッシュバック・システム１２２０へと送信可能である。
アプリケーション層セキュリティ・システム
図１５は本明細書で詳細に後述するメッセージ質問エンジン（ＭＩＥ）の例４０３５を通るメッセージの流れを示している。ＭＩＥは質問するためのルールおよび方針を用いることができる。ＴＭＣからの入力はルールおよび１組のルールと方針４００５に加えることができる。ＭＩＥはレコードされた履歴に基づいて１組の統計４０１０を作成する。統計処理モジュール（ＳＰＭ）４０２５はこの情報を処理し、それを配信用に準備することができる。ある情報は分析４０３０のためにＴＭＣに返送可能である。情報はピア・ベースの脅威通知システムの一部としてピア４０１５に、またそこから送信可能である。情報はさらに、脅威プッシュバック・システム４０２０を利用してソースの方向に押し戻すことができる。ＳＰＭ４０１０はさらに、ピア・ベースの脅威通知システムおよび脅威プッシュバック・システムからの入力も受信できる。ＳＰＭ４０１０はその履歴と分析とに基づいて、ローカルＭＩＥ用の新たなルールおよび方針４００５を作成することができる。

図２は本発明による典型的な環境を示している。図１と比較して、本発明によるシステムおよび方法を利用したアクセス環境は、イーサーネット１８０のようなローカル通信ネットワークに接続され、ファイヤウォール・システム１４０とローカル・サーバー１２０とクライアント１３０との間に論理的に挿入されたハードウエア・デバイス２１０を含んでいてもよい。ファイヤウォール・システム１４０を経てローカル通信ネットワークに出入りしようとするあらゆるアプリケーション関連電子通信は、アプリケーション・レベルのセキュリティ査定および／または異常検出のためにハードウエア・デバイス２１０へと転送される。ハードウエア・デバイス２１０はローカル通信ネットワークを管理する既存のハードウエア素子から物理的に離される必要はない。例えば、本発明による方法およびシステムは標準型のファイヤウォール・システム１４０または同様の機能を有するルータ（図示せず）へと組み込むことができよう。ファイヤウォール・システムを利用しない環境では、ハードウエア・デバイス２１０が引き続きアプリケーション・レベル・セキュリティ査定および／または異常検出を行うことができる。

便宜上、および説明目的のみで、上記の説明ではハードウエア・デバイス２１０を参照している。しかし、本発明によるシステムおよび方法を実施するために使用されるハードウエアおよび／またはソフトウエアは、他の適宜のネットワーク管理ハードウエアおよびソフトウエア要素内にあってもよいことが当業者には理解されよう。さらに、ハードウエア・デバイス２１０は単一の素子として図示されている。ｅ−メールまたはＷｅｂのような特定の種類のアプリケーション・サーバー用のセキュリティを強化する複数のデバイスを使用してもよく、その場合は特定の種類の通信が例えば（１）通信を各デバイスに逐次割り当てる逐次割り当て、（２）現在のデバイスの負担に基づいて通信をデバイスに割り当てる、ハードウエアおよび／またはソフトウエア負荷平衡器の使用による割り当てのような適宜の割り当て戦略によって複数のデバイス間に割り当てられる。単一のデバイスが複数の種類のアプリケーション・サーバー全体に強化されたセキュリティを提供してもよく、または各デバイスが単一の種類のアプリケーション・サーバーだけに強化されたセキュリティを提供してもよい。

一実施形態では、ハードウエア・デバイス２１０は１Ｕまたは２Ｕサイズのラックマウント形のインテル・ベース・サーバーでよい。ハードウエア・デバイス２１０は利用可能性と拡張性を高めるために電源、プロセッサ、ディスクアレイのような冗長構成部品で構成されることができる。ハードウエア・デバイス２１０は暗号化されたメッセージの性能を増強するためにＳＳＬ／ＴＬＳアクセレータを含んでいてもよい。

ハードウエア・デバイス２１０は潜在的に複数の処理要素を含むシステム・プロセッサを含み、各処理要素は好適には少なくとも１つのＰＥＮＴＩＵＭ（登録商標） ＩＩＩまたはＣＥＬＥＲＯＮ（インテル社、カリフォルニア州、サンタクララ）クラスのプロセッサによってサポートされてもよい。あるいは別の実施形態ではＵｌｔｒａＳＰＡＲＣ（サン・マイクロシステムカリフォルニア州パロアルト）を使用することができよう。ある実施形態では、以下にさらに記載するように、セキュリティ強化機能を複数の処理要素間に分散してもよい。処理要素という用語は（１）特定の部品で、または特定の複数の部品にわたって動作する処理、（２）特定のハードウエア部品、または文脈に沿う限り（１）または（２）のいずれかのことである。

ハードウエア・デバイス２１０は多様な一次または二次記憶素子を含むことがあるＳＤＳを有するであろう。好適な一実施形態では、ＳＤＳは一次記憶装置の一部としてＲＡＭを含むであろう。ＲＡＭの容量は１２８ＭＢから４ＭＢの範囲であろうが、これらの数量は可変的であり、本発明によるセキュリティ強化がファイヤウォール・システムに組み込まれる場合のように重複利用を表すことができよう。一次記憶装置はある実施形態ではキャッシュメモリ、レジスタ、不揮発性メモリ（例えばＦＬＡＳＨ、ＲＯＭ、ＥＰＲＯＭなど）などのような他の形式の記憶装置を含んでいてもよい。

ＳＤＳはさらに、単一、多重、および／または可変サーバーおよび記憶素子を含む二次記憶装置を含んでいてもよい。例えば、ＳＤＳはシステム・プロセッサに接続された内部記憶装置を使用してもよい。単一の処理要素はセキュリティ強化機能の全てをサポートする実施形態では、ローカル・ハードディスク・ドライブはＳＤＳの二次記憶装置として機能してもよく、このような単一の処理要素上で実行されるディスク・オペレーティングシステムはデータ・要求を受信し、サービスするデータ・サーバーとして機能してもよい。

本発明によるセキュリティ強化工程およびシステムで利用される異なる情報は、ＳＤＳ用の二次記憶装置として機能する単一のデバイス内で論理的、または物理的に下記のように区分されてもよいことが当業者には理解されよう。すなわち、共にＳＤＳとして機能する統一管理システムを介してアクセス可能な複数の関連データと、実施形態によっては全体としてＳＤＳと見なされてもよい異種の管理システムを介して個々にアクセス可能な複数の独立したデータ・ストアである。ＳＤＳの物理的構造を構成する多様な記憶素子は集中して配置してもよく、または多様な異なる位置にわたって分散されてもよい。

システム・データ・ストアの二次記憶装置のアーキテクチャは異なる実施形態では大幅に変化することがある。幾つかの実施形態では、データを記憶し、処理するためにデータベース（単数または複数）が使用される。このような実施形態のあるものでは、ＤＢ２（ＩＢＭ、ニューヨーク州ホワイトプレーン）、ＳＱＬサーバー（マイクロソフト、ワシントン州レッドモンド）、ＡＣＣＥＳＳ（マイクロソフト、ワシントン州レッドモンド）、ＯＲＡＣＬＥ８ｉ（オラクル社、カリフォルニア州レッドウッド ショアー）、Ｉｎｇｒｅｓ（コンピュータ・アソシエーツ、ニューヨーク州アイランディア）、ＭｙＳＱＬ（ＭｙＳＱＬ ＡＢ スエーデン）、または適応サーバー・エンタープライス（Ｓｙｂａｓｅ Ｉｎｃ．カリフォルニア州エミリービレ）のような１つ以上の関連データベース管理システムを、それに限定されるものではないがＩＤＥおよびＳＣＳＩを含む任意の適宜のインターフェースを使用した１つ以上の標準型の磁気および／または光ディスクを含んでいてもよい多様な記憶デバイス／ファイルと共に使用してもよい。ある実施形態では、Ｅｘａｂｙｔｅ Ｘ８０（イグザバイト・コーポレーション、コロラド州ボールダー）のような、テープ・ライブラリ、ＥＭＣ Ｉｎｃ．（マサチューセッツ州ホプキントン）から市販されているようなストレッジ・アタッチト・ネットワーク（ＳＡＮ）の解決手段、ＮｅｔＡｐｐフィルタ７４０（ネットワーク・アプリカンス、カリフォルニア州サンバレー）のようなネットワーク・アタッチト・ストレッジ（ＮＡＳ）の解決手段、またはそれらの組み合わせを使用してもよい。別の実施形態では、データ・ストアはオブジェクト指向、空間、オブジェクト関連、または階層的構造のような別のアーキテクチャのデータベースを使用してもよく、またはハッシュテーブルまたはフラット・ファイル、またはそのようなアーキテクチャの組み合わせを使用してもよい。このような代替アプローチは、ハッシュテーブル参照用サーバー、手順および／または工程、および／またはフラット・ファイル検索サーバー、手順および／または工程のようなデータベース管理システム以外のデータ・サーバーを使用してもよい。さらに、ＳＤＳはその二次記憶装置のアーキテクチャを組成する際に上記のアプローチのどの組み合わせをも利用できる。

ハードウエア・デバイス２１０はＷＩＮＤＯＷＳ（登録商標）／ＮＴ、ＷＩＮＤＯＷＳ（登録商標）２０００、またはＷＩＮＤＯＷＳ（登録商標）／ＸＰサーバー（マイクロソフト、ワシントン州レッドモンド）、Ｓｏｌａｒｉｓ（サン・マイクロシステムカリフォルニア州パロアルト）、またはＬＩＮＵＸ（またはその他のＵＮＩＸ（登録商標）のバリエーション）のような適宜のオペレーション・システムを有しているであろう。好適な一実施形態ではハードウエア・デバイス２１０は、ＦｒｅｅＢＳＤ（ＦｒｅｅＢＳＤ．Ｉｎｃ．，ｈｔｔｐ：／／ｗｗｗ．ｆｒｅｅｂｓｄ．ｏｒｇ）に基づく、事前にロードされ、事前に構成され、強化されたＵＮＩＸ（登録商標）オペレーティングシステムを含んでいる。この実施形態では、ＵＮＩＸ（登録商標）カーネルは大幅に縮減され、不可欠ではないユーザー・アカウント、不要なネットワーク・サービス、およびセキュリティ強化工程には必要ないいかなる機能をも除去している。オペレーティングシステム・コードはセキュリティの脆弱性をなくするように大幅に修正されている。

ハードウエア／オペレーティングシステム・プラットフォームに応じて、構成、監視および／または報告の目的の所望のアクセスをサポートするため、適宜のサーバー・ソフトウエアを含めてもよい。Ｗｅｂサーバーの機能はインターネット情報サーバー（マイクロソフト、ワシントン州レッドモンド）、アパッチＨＴＴＰサーバー（アパッチ・ソフトウエア・ファンデション、メリーランド州フォーレストヒル）、ｉＰｌａｎｅｔ Ｗｅｂサーバー（ｉプラネットＥ−コマース・ソリュージョン−Ａ−Ｓｕｎ−ネットスケープ アライアンス、カリフォルニア州マウンテンビュー）、またはその他の適宜のＷｅｂサーバー・プラットフォームを介して供給されることができる。ｅ−メール・サービスは交換サーバー（マイクロソフト、ワシントン州レッドモンド）、センドメールまたはその他の適宜のｅ−メール・サーバーによってサポートされることができる。ある実施形態は前述のアクセス・サーバーに加えて、または代替として１つ以上の自動音声応答（ＡＶＲ）システムを含んでいてもよい。このようなＡＶＲシステムは、（例えばプリンタ、ファクシミリなどのような）適宜のハードコピー出力デバイスに電子的に配信され、必要に応じて通常の郵便、宅急便（登録商標）、オフィス内メール、ファクシミリ、または他の適宜の送達アプローチを介して送られるハードコピー出力を伴う環境への純粋な音声／電話励起インターフェースをサポートできよう。好適な一実施形態では、アパッチ・サーバーのバリエーションがハードウエア・デバイス２１０を遠隔構成するためのインターフェースを提供する。構成、監視および／または報告はある形態の遠隔アクセス・デバイスまたはソフトウエアを利用して提供されることができる。好適な一実施形態では、ＳＮＭＰを利用してデバイスが構成および／または監視される。好適な一実施形態では、任意の適宜の遠隔クライアント・デバイスを利用してハードウエア・デバイス２１０へ、またそこから情報およびコマンドが送信され、検索される。このような遠隔クライアント・デバイスは従来のワークステーションまたは携帯用ワイヤレス・デバイスのような任意の適宜のプラットフォーム上で動作するＪａｖａ（登録商標）クライアントまたはウインドウズ・ベースのクライアントの形式で、またはこれも従来のワークステーションまたは携帯用ワイヤレス・デバイスを含む適宜のプラットフォームで動作する所有者クライアントの形式で提供されることができる。
アプリケーション層電子通信セキュリティ強化
図３は本発明によるセキュリティ強化システムの論理構成要素の構成図である。全般的な分析、報告、および監視機能はブロック３１０によって示され、異常検出はブロック３７０によって示されている。

ブロック３２０−３６０は電子通信になされる異なる査定を示している。これらのブロックは実行できる査定を示すものであり、可能なあらゆる種類のアプリケーション・サーバー用の可能なあらゆる査定を網羅した表示をなすものではない。“テスト”、および“テストする”という用語は本明細書、および下記の特許請求の範囲の記載で適当に“査定”または”査定する”と互換的に用いてもよい。

・アプリケーション特有のファイヤウォール３２０はアプリケーション特有の攻撃に対して防御する機能を果たす。例えばｅ−メールの文脈では、この査定は拡張ＳＭＴＰ、バッファのオーバーフロー、およびサービス拒否に向けられた攻撃に対して防御可能であろう。

・アプリケーション特有のＩＤＳ３３０はアプリケーション・サーバー特有の活動をリアルタイムで監視する。これはさらに、アプリケーション層、ネットワーク層、およびオペレーティング層を含む複数の層からの情報をも検索できる。これはアプリケーション特有のＩＤＳ監視の追加層を追加することによってネットワーク侵入検出システムを補う。

・アプリケーション特有のアンチウイルス防御およびアンチスパム防御３４０はアプリケーション特有の通信から関連するウイルスおよび／またはスパムを除去することをサポートする。

・方針管理３５０によって、アプリケーション特有のどの通信がいかにして送信され、コピーされ、またはブロックされるかに関する特定のアプリケーションに対する企業の方針を規定することが可能になる。しばしばウイルスおよび／またはウオームのソースとなる実行可能な添付または通信コンポーネントおよび／または疑念があるコンテンツはそれらがアプリケーション・サーバーまたはクライアントに到達する前に排除または、隔離されることができる。競合相手からのｅ−メールはブロック、またはコピーされることができる。言語メッセージはネットワークの輻輳を防止するためにピーク外時間に追いやる（ｒｅｌｅｇａｔｅ）ことができる。

・アプリケーション暗号化３６０はアプリケーション通信を確実に送受信し、ハードウエアの性能促進を潜在的に強化する。

アプリケーション・セキュリティ・システムは着信する通信を処理し、ネットワークの侵入者にとって実際のアプリケーション・サーバーであるように見える。それによって実際の企業アプリケーション・サーバーは直接、間接の攻撃が防止される。

ローカル通信ネットワークに出入りしようとする電子通信は査定のために本発明を通って転送されることができる。この査定の結果は、そのメッセージが対象となる受信者に配信されるか否かを決定することができる。

着信および送信通信、およびその添付メールは本発明によるセキュリティ・システムによって受信される。好適な一実施形態における通信はｅ−メール・メッセージである。別の実施形態での通信はＨＴＴＰ要求または応答、ＧＯＰＨＥＲ要求または応答、ＦＴＰコマンドまたは応答、テルネットまたはＷＡＩＳインタラクション、またはその他の適宜のインターネット・アプリケーション通信であってよい。

本発明によるホワイトリスト作成の自動化によって、システムはアウトバウンドのｅ−メール・トラフィックに基づいて１つ以上のホワイトリストを自動的に作成および／または保存することが可能になる。ある実施形態では、システムはアウトバウンドのおよび／またはインバウンドのｅ−メール・トラフィックを監視し、それによってホワイトリストに加えられる適正なｅ−メール・アドレスを判定することができる。ソフトウエアはどのアウトバウンド・アドレスが実際に適正なアドレスであるかを決定するために１組のメトリクスを利用できる。

受信された通信に１つ以上の査定戦略を適用するデータ収集工程が実施される。上記に概説出力、下記に詳細に説明する多重待ち行列質問アプローチは好適な一実施形態ではデータ収集機能を備えている。あるいは、査定は受信された各メッセージで並行して行われてもよい。システム・プロセッサの別個の処理要素は受信されたメッセージにそれぞれの査定を加える役割を担うであろう。一実施形態では、ニューラル・ネットワークのようなアプローチを利用して受信された通信で同時に複数のリスク査定を行うことができる。各査定、または査定全体の適用によって、受信された通信に関連する１つ以上のリスク・プロファイルが生成される。受信された通信の査定に基づいて作成されるリスク・プロファイルまたはログ／ファイルはＳＤＳ内に記憶される。収集されたデータは脅威の分析または鑑定を行うために利用できる。この工程は通信が既に受信され、送出された後で行ってもよい。

好適な一実施形態では、特定の査定がアプリケーション管理者によって構成可能にイネーブルまたはディスエーブルにされることができる。上記のように、アプリケーション管理者による構成を容易にするために適宜の構成インターフェース・システムを備えてもよい。

異常検出工程は、以前に受信された通信に関連するデータにかんがみて異常であるか否かを判定するために、受信された通信に関連する記憶されたリスク・プロファイルを分析する。好適な一実施形態では、上記に概説し、下記に詳述する異常検出工程がこの検出機能をサポートする。ある実施形態での異常検出は査定と同時に行ってもよい。例えば、複数のリスクに関して受信された通信を同時に査定するためのニューラル・ネットワークを利用した実施形態は、受信された通信の異常をさらに分析できる。このような実施形態では、以前に受信された通信に関連するデータはニューラル・ネットワーク内での重み係数としてエンコードされることができる。

ある実施形態では、様々な種類の異常性の閾値を以前受信された通信に関連するデータに基づいて動的に決定してもよい。あるいは、個々の種類の異常性に関する特定の閾値を構成できるようにアプリケーション管理者にインターフェースを備えてもよい。ある実施形態では、閾値はアプリケーション管理者によって特別に構成されない限り、動的に導出できる。

異常性は典型的には特定の期間に基づいて検出される。このような期間は特定の固定期間（例えば先月、昨日、去年、セキュリティ・デバイスの最後の再起動以来など）であってよく、全ての種類の異常に適用される。あるいは、アプリケーション管理者によって適宜のインターフェースを介してあらゆる種類の異常性、または各種の異常性ごとに個別にそれぞれの期間を構成することもできる。ある実施形態はあらゆる種類の異常性、または各種の異常性ごとに個別に固定期間のデフォールトをサポートしてもよく、これはアプリケーション管理者の構成によって無効にされることができる。

好適な一実施形態では、受信された通信に関連する記憶されたリスク・プロファイルは同じ種類の以前受信された通信に関連するデータと統合される。この新たな統合された１組のデータは次に、後に受信されるその種類の通信の分析に利用される。

異常が検出されると、異常表示信号が出力される。出力される信号は検出された異常と、異常が検出された通信とを特定するデータを含むことができる。ｅ−メール・アプリケーション・セキュリティに関する様々な種類の異常性を以下に記載する。これらの種類の異常性は以下に記載する特定の検出アプローチ、または前述のいずれかの異常検出の代替アプローチを利用して検出できる。

出力された信号はある実施形態ではさらに別の応答をトリガしてもよい。あるいは、出力された信号が応答であってもよい。好適な一実施形態では、出力された信号は１つ以上のそれぞれ特定された配信プラットフォームを介して１人以上の指定の受信者に対する通知であってよい。例えば、通知はｅ−メール・メッセージ、ページ、ファクシミリ、ＳＮＭＰ（簡易ネットワーク管理プロトコル）警報、ＳＭＳ（ショート・メッセージ・システム）メッセージ、ＷＡＰ（ワイヤレス・アプリケーション・プロトコル）警報、音声通話またはその他の適宜なメッセージで警告するＯＰＳＥＣ（オペレーション・セキュリティ）の形態のものでよい。あるいは、このような通知は出力された信号によってトリガされることもできよう。

ＳＮＭＰを利用すると、マネージャーおよびエージェントを利用してネットワーク・レベルのセキュリティとインターフェースすることが可能になる。一例として、特定のルータを通るトラフィックの流れの監視があげられよう。ＯＰＳＥＣは重要な情報を保護するための公式の工程および方法である。ＷＡＰはワイヤレス・デバイスを有するモバイルのユーザーが瞬時に情報およびサービスに容易にアクセスし、これとインタラクトする権限を与える公開のグローバルな規格である。その例には、異常が検出された場合にＷＡＰをサポートするワイヤレス・デバイスへとＷＡＰページをフォーマット化することがあげられよう。ＷＡＰページはＨＴＭＬの簡易バージョン（ｓｔｒｉｐｐｅｄ ｄｏｗｎ ｖｅｒｓｉｏｎ）であり、ディスプレーが小さいワイヤレス・ネットワークおよびデバイス用に最適化されている。ＳＭＳはＮｏｋｉａ８２６０電話のようなワイヤレス・デバイスに短いテキスト・メッセージを配信する伝送用にＳＭＴＰおよびＳＮＭＰを利用するワイヤレス技術である。ＳＭＳメッセージはユーザーに対して異常警報の侵入検出を警報するためにこれらのデバイスに送信可能であろう。

通知の代わりに、または通知に加えて、出力された信号によって１つ以上の修正手段がトリガ可能であろう。このような修正手段には受信された通信のソースからのそれ以上の通信の受信拒否、通信の隔離、アプリケーション・サーバーによって安全に処理されるようにするための通信のストリッピング、および／または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによってメッセージング可能なレベルまで抑制することを含めることができよう。

好適な一実施形態では、アプリケーション管理者が所望の応答を選択的に構成でき、構成されたこの応答を特定の種類の異常と関連付けることによって、その種類の異常が検出されると、構成された応答が行われるようにするインターフェースを備えてもよい。

最後に、受信された通信に関して異常が検出されると、その通信は対象となる宛先に送出されても、されなくてもよい。異常であると判定された通信が送出されるかされないかは、ある実施形態では、あらゆる種類の異常に対して構成可能である。あるいは、個々の種類の異常に関して異常な通信の送出を構成することもできよう。このような実施形態のあるものでは、特別に構成されない個々の種類の異常に関してデフォールト・フォワーディングの設定を利用できよう。
セキュア通信配信
本発明によって実施される通信サービスは１つのシステム・プロセッサ上で実行可能であり、または複数のシステム・プロセッサに分散されてもよい。本発明の全ての関連機能は１人以上の管理者によって構成されることができる。好適な一実施形態は管理者が認可およびユーザー／ドメイン管理および機能構成を行うためのインターフェースを含むことができる。ユーザー・パラメータおよび認可の管理用にユーザー管理インターフェースを備えることができる。本発明は、いずれかの機能がメニュー方式のシステムで構成するためのインターフェースを有することができるように、プログラムまたは適応化することが可能である。

図１６を参照した好適な一実施形態では、インバウンド通信の処理工程は所定の受信者５００５に配信するように指定された電子通信の受信で開始される。受信された通信は、必ずしもすべての実施形態で層である必要はないが、脅威および／または異常の検出に関連して上述し、また後述するテストおよび分析を受ける。受信された通信５０１０と共に使用されるセキュア配信機構が選択される。この機構は利用できる配信機構の優先順位付けに基づいて選択される。選択された機構５０１５にしたがってメッセージを配信することが試行される。この試行が成功した場合は５０２０、工程は完了する５０２５。ある実施形態では、配信の試行が失敗すると、選択および配信試行工程を付加的に選択された配信機構で繰り返すことができる。このような実施形態のあるものでは、繰り返しは通信の配信に成功するまで、または利用できる全ての配信機構が試行されるまで継続可能である。ある実施形態では、セキュア配信機構を利用できない場合、または利用できるすべてのセキュア配信機構が失敗した場合はインセキュア配信が実施される。

好適な一実施形態では、配信機構はベース機構および１つ以上のオプションを含むことができる。ベース機構は好適にはインスタント・メッセージイング、ＳＭＴＰ、ＨＴＴＰ、またはＦＴＰである。一般に使用されている他の配信機構も適宜に使用可能であることが当業者には理解されよう。配信機構はさらにセキュリティ・オプションを含むことができる。これらのオプションは好適にはＨＴＴＰ提示を伴うＳＭＴＰ通知、Ｓ／ＭＩＭＥ、ＰＧＰ、ＴＬＳ、ＳＳＬおよびこれらの組み合わせを含むことができる。しかし、当業者には公知の他のチャネルおよび／またはメッセージ・レベル・セキュリティ技術も利用可能であろう。配信機構は適宜のメッセージ・レベル暗号化技術、チャネル・レベル暗号化技術、または２つの組み合わせを利用することができる。ある実施形態では、利用可能な配信機構を通信ソース、所定の受信者、デフォールト構成、またはそれらの組み合わせに基づいて選択することができる。

セキュア配信機構を選択する際、選択工程は利用可能なセキュア配信機構の決定と、このような機構の優先順序付けとを含んでいてもよい。決定および優先順位付けは、ある実施形態では、デフォールト優先順序付けによって規定された順序での特定の配信機構の利用可能性を逐次チェックし、このような利用できる最初の機構を選択するデフォールト優先順序付けの場合のように、選択工程と同時に、またはその一部として行われることができる。図１７はこのような工程の１つを示している。

好適なある実施形態では、配信機構は各配信機構に関連する格付けに基づいて優先順序を決めることができる。配信機構の優先順序付けは受信者または通信ソースに基づいて検索可能である。加えて、ある実施形態では、複数の配信機構の優先順序を指定するためのインターフェースを通信ソースに備えることができる。次にその優先順序は備えられたインターフェースから検索できる。それに加えて、またはその代替として、受信者が配信機構のデフォールト優先順序を指定できるようにするインターフェースを受信者に供給することができる。この構成情報は供給されたインターフェースから受信され、その受信者への通信のセキュア配信のために利用される。

好適な一実施形態では、各配信機構に格付けをすることができる。格付けは配信効率、配信コスト、配信のセキュリティ、およびそれらの組み合わせを含む様々な判断基準に基づいて行われることができる。

その代替として、あるいはその代わりに、複数の配信機構の優先順序を指定するためのインターフェースを管理者に供給することができる。指定された優先順位情報は次に、供給されたインターフェースから受信可能である。管理者によって指定された構成は例えば、配信機構のデフォールト優先順序を指定するために利用できる。

ある実施形態では、通信がセキュア配信を要求しているかの判定が行われる。セキュア配信の要求は通信ソース、通信コンテンツ、通信の受信者、構成データ、およびこれらのベースの組み合わせに基づいて多くの態様で判定される。通信のコンテンツはセキュア配信が所望されていることを示すインデックスについてパーズされることができる。受信された通信は次に、パージングに基づくセキュア配信の要求として特定されることができる。パージングは受信された通信に１つ以上のフィルタリング・ルールを適用することによって実施可能である。フィルタリング・ルールはコンテンツ、添付、ソース、受信者、または当業者が適切であると認識するその他のインデックスに基づくものでよい。ある実施形態では、パージングハ例えばＳＭＴＰｅ−メール・メッセージまたはＨＴＴＰ要求または応答のヘッダ部分のような通信のヘッダ部分に限定されてもよい。１つ以上の所定のキーワードが受信された通信またはそのヘッダからパーズされた場合は、受信された通信はセキュア配信を要求しているものと特定できる。その代わりに、またはそれに加えて、セキュア配信を決定するために通信のソースまたは受信者を利用することができる。例えば、特定の受信者への、または特定のソースからの全てのメッセージがセキュア配信を要求しているものとすることができよう。さらに、管理者によって、または通信ソースから提示された構成データがセキュア配信のための特定の通信を指定する役割を果たすことがかのうであろう。

本発明は配信される通信用のメッセージ・レベルおよびチャネル・レベルのセキュリティのいずれかの組み合わせを利用し、または利用を試行するように構成可能である。受信者およびドメインはデータベース内で多様なセキュア配信機構と関連付けすることができる。配信機構は上述のように優先順序付けが可能である。順序付けされた優先順序は配信機構、配信機構のベース機構、配信機構のセキュリティ・オプション（単数または複数）、またはそれらの要因の組み合わせに基づいて利用できる。好適な一実施形態では、順序付けされた優先順序は下記のように最高から最低までの配信機構に関連するセキュリティ・オプションに基づいている。すなわち、Ｓ／ＭＩＭＥ、ＰＧＰ、パスワードおよびランダムＵＲＬ付きのＳＷＭ（セキュアＷｅｂメール）、ＴＬＳまたはＳＳＬ、ランダムＵＲＬ付きのＳＷＭである。別の優先順序を用いてもよいことが当業者には理解されよう。このような代わりの順序は上記にリストしてセキュア配信機構の全部または一部を含むことができ、または含まないこともある。

好適な一実施形態では、図１７に示すように、ＰＧＰ、Ｓ／ＭＩＭＥ、ＴＬＳまたはＳＳＬ、（ユーザー認証付き、またはなしの）ＳＷＭのセキュリティ・オプションに基づくデフォールト優先順序付けが利用される。通信が受信される５１００。段階５１０５、５１１５、５１２５、および５１３５に示すように、セキュア配信機構の選択はセキュリティ・オプションの暗黙的デフォールト優先順序付けにしたがって行われる。利用可能なセキュア配信機構の決定は下記の選択で同時に行われる。

ある実施形態では、段階５１５０で配信が失敗した場合はループバックを行うことが可能である。ループバックの結果、失敗した機構の後で次に利用できる機構に戻るであろう。例えば、ＰＧＰを利用できると判定されたが失敗した場合は、ループバックが段階５１１５で工程に再び入って、Ｓ／ＭＩＭＥの利用可能性が判定されよう。このような代替機構では、次の段階に進む決定は、特定のセキュリティ・オプションの利用可能性の代わりに、またはそれに加えて配信の成功または失敗に基づいて行われる。これに加えて、または代替実施形態では、インセキュア配信段階は完全に除去されるか、または段階５１０５へのループバックで代替され、利用可能なセキュア配信機構が見つかるまでそのチェックを継続することができる。加えて、ループが固定回数だけ、または固定期間だけ行われるように、このようなループバックに制約を加えることができよう。

本発明は独立して、または上記の、および後述とは別のネットワーク管理方法およびシステムと共に動作することができる。本発明の下記の構成要素を本発明に組み込むことができる。一旦組み込まれると、これらは別個に、または組み合わせて構成可能である。
セキュアＷｅｂメール（ＳＷＭ）
ＳＷＭはオリジナル・メッセージにアクセスするためのセキュア・ウエブ・ページへのリンクで受信者に通知メッセージを送信する。提供されたリンクがたどられると、受信者のブラウザはオリジナル・メッセージを含むサーバーとのセキュア接続を確立することができる。その後、メッセージをセキュアに閲覧できる。ブラウザ接続を介したメッセージへのアクセスも適宜な認証手段によってセキュリティを保つことが可能である。限定的ではない例として、ユーザー・アクセスの認証はランダムＵＲＬ、ユーザーネーム／パスワードの組み合わせ、またはこれらの組み合わせに基づくものでよい。

好適な一実施形態では、既読または未読のメッセージを保存するために、受信者用の管理インターフェースを供給することができる。限定的ではない例として、メッセージが一度閲覧されるとこれを削除するようにシステムを構成することができる。

ＳＷＭによって配信されるメッセージの各受信者向けに、ランダム・ストリングを生成可能であり、これを用いてＵＲＬを作成可能である。例えばＵＲＬ ｈｔｔｐ：／／ｂｏｘｎａｍｅ／ｍｓｇ．ｊｓｐ？ｒａｎ＝１２ｆｕｇｒ１９８０ｄｈ８９を利用できよう。本発明はＵＲＬを封入したｅ−メールを作成できる。このようなｅ−メールは、含まれているリンクでメッセージを検索可能であることを受信者に伝えるために利用できる。本発明のある実施形態はユーザーネーム／パスワードまたはセキュアＩＤ認証機構を利用して追加認証を供給することができる。本発明のある実施形態は、ブラウザ・リンクを含むメッセージを表示する前にユーザー認証を行うように構成することができる。

ＳＷＭは１つ以上の処理要素上で実行可能である。これらの処理要素は本発明のシステム・プロセッサの一部であってもよく、またはこれらとシステム・プロセッサとの間の通信リンクを別個に備えることもできる。いずれの場合も、受信された通信は本発明のＳＤＳ、または別個に備えられた処理要素に関連するある記憶装置へとコピーされる。ある実施形態では、ＵＲＬを作成するために通信のコピーの位置を利用できる。しかし、別の実施形態はコピーの位置に関わりなくＵＲＬを作成できる。

ＳＷＭはメッセージ・レベル暗号化（例えばＳ−ＨＴＴＰ、Ｓ／ＭＩＭＥ、ＰＧＰなど）および／またはチャネル・レベル暗号化（例えばＳＳＬまたはＴＬＳ）を利用した適宜の暗号化によって受信された通信をセキュアに提示する。好適な一実施形態では、ＳＳＬチャネル・レベル暗号化はセキュア提示を行うためのセキュリティ・オプションとしての役割を果たす。暗号化で使用される様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに利用できる。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼され、認証された）キー・サーバーからこのようなキーを取得できる。
サーバー・ベースのＰＧＰ
サーバー・ベースのＰＧＰを含む実施形態はサーバー・ベースのＰＧＰメッセージを送信および／または受信するようにプログラムされ、または適応化されることができる。サーバー・ベースのＰＧＰは信頼性、認証、およびメッセージの完全性の保証を得ることが望まれる環境で使用することができる。この機能はＰＧＰフリーウエア（マサチューセッツ技術研究所、マサチューセッツ州ケンブリッジ）のようなツールキットを使用して実装可能であり、またはネットワーク・アソシエーツ・テクノロジーＩｎｃ．（カリフォルニア州サンタクララ）から供給されている。

好適な一実施形態はＰＧＰ／ＭＩＭＥフォーマットを使用してメッセージを送信および／または受信できるドメインおよび／またはユーザーを管理する構成インターフェースを含むことができる。この管理インターフェースはさらにドメインのための公開鍵管理機能をも提供できる。本発明はＰＧＰ／ＭＩＭＥメッセージ・レベルの暗号化が必要であると指定された受信者またはドメイン用に、オリジナル・メッセージからＰＧＰ／ＭＩＭＥメッセージを作成するように構成できる。暗号化に使用されるための様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに利用可能である。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼され、認証された）キー・サーバーからこのようなキーを取得することができる。
着信メッセージ
本発明の好適な一実施形態では、着信メッセージの受信者またはドメインがデータベース内でＰＧＰユーザー・リスト上の受信者またはドメインと一致できた場合は、対応する公開鍵を使用してメッセージを解読できる。送信者の認証を行うこともできる。
発信メッセージ
好適な一実施形態では、発信メッセージの受信者またはドメインをＰＧＰユーザー・リストに対してチェックすることができる。受信者または宛先ドメインがＰＧＰユーザー・リストに出現する受信者またはドメインと一致すると、ＰＧＰ／ＭＩＭＥフォーマットを用いて新規の通信を作成できる。新規の通信は．ｐｇｐ拡張、またはその他の適宜の命名規則を有するオリジナルのファイルネームを使用して作成できる。作成後、適宜のプロトコルに従った工程が暗号化された通信を配信することができる。
サーバー・ベースのＳ／ＭＩＭＥ（セキュア／多目的インターネット・メール拡張）
本発明のある好適な実施形態はサーバー・ベースのＳ／ＭＩＭＥメッセージを送受信する能力を含むことができる。Ｓ／ＭＩＭＥはプライバシー、完全性を増強し、認証を与えるために利用できる。本発明はＳ／ＭＩＭＥフォーマットを要求するように指定されたオリジナル・メッセージの受信者および／またはドメインからＳ／ＭＩＭＥメッセージを生成することができる。この機能は構成可能にターンオンまたはターンオフできる。

サーバー・ベースのＳ／ＭＩＭＥの機能はＳ／ＭＩＭＥツールキットを使用して実現可能である。ある好適な実施形態はＳ／ＭＩＭＥフォーマットをしようしてメッセージを受信および／または送信できるドメインおよびユーザーを管理するための構成インターフェースを含むことができる。ドメインの公開鍵の管理用のインターフェースも備えることができる。暗号化に使用される様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに入手できる。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼できる認証された）キー・サーバーからこのような鍵を入手することができる。
着信メッセージ
着信メッセージはそれがＳ／ＭＩＭＥフォーマットのものであるか否かをチェック可能である。メッセージの受信者または宛先ドメインが多くのＳ／ＭＩＭＥユーザー・リストと一致すると、メッセージは対応する公開鍵を用いて解読される。送信者の認証も行うことができる。
発信メッセージ
発信メッセージの受信者はＳ／ＭＩＭＥユーザー・リストに対してチェック可能である。受信者または宛先ドメインがＳ／ＭＩＭＥの暗号化を要求またはサポートしている場合は、Ｓ／ＭＩＭＥフォーマットに基づいて新規のメッセージを作成可能である。新規のＳ／ＭＩＭＥメッセージは．ｓｍｉｍｅ拡張、またはその他の適宜の命名規則を有するオリジナルのファイルネームを使用して作成できる。そこで本発明はＳ／ＭＩＭＥメッセージを対象とされる受信者に配信することができる。
ＳＳＬ／ＴＳＬ
好適なある実施形態では、ＳＳＬ／ＴＬＳまたはその他の適宜のセキュア・チャネル・プロトコルを用いたセキュア通信チャネルを利用して配信されることができる。受信者または宛先ドメインがチャネル・レベルの暗号化を要求またはサポートしている場合は、このようなチャネルを利用してメッセージを配信可能である。暗号化で使用される様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに利用できる。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼され、認証された）キー・サーバーからこのようなキーを取得できる。
脅威管理センター
ＴＭＣシステムは１つ以上のアプリケーション層および／またはネットワーク層セキュリティ・システムと共にコンピュータ・システム上に常駐可能である。ＴＭＣ用の典型的なハードウエア構成には、アプリケーション層セキュリティ・システムに関して前述したと同様の容量を有するものでよいシステム・プロセッサおよびシステム・データ・ストアを含んでいる。典型的には、通信はインターネットのようなコンピュータ・ネットワークを介して行うことができる。しかし、直接接続およびダイアルアップ・アクセスを含む別の機構を介して１つ以上のシステムをＴＭＣに接続することができる。

ＴＭＣは少なくとも１つの入力と、処理システムと、少なくとも１つの出力とを含んでいる。図１３はＴＭＣの例におけるルール作成工程の流れ図を示している。入力２００５はメッセージ、メッセージング・システム、攻撃、脆弱性、これらに関連する脅威、または当業者が脅威分析に関連すると思う他のいずれかの情報であることができる。加えて、１つ以上のアプリケーション層セキュリティ・システムによってＴＭＣへのフィードバックを行ってもよい。ＴＭＣ２０１０の最終的な出力は、アプリケーション層セキュリティ・システムによって判明し、または判明していない双方の脅威に対して防護するために利用できるルールおよび／または方針を含むことができる。これらのルールおよび／または方針２０１０は１つ以上のアプリケーション層セキュリティ・システムによって利用されることができる。

好適な一実施形態では、ルールおよび方針の作成は受信された脅威情報の集合に基づいて行うことができる。情報は１つ以上のＭＳＳまたはＴＭＣと通信するように構成されたほかのいずれかの脅威情報源から受信することができる。

ＴＭＣ２０１０の出力はルールおよび方針アプリケーション・プログラミング・インターフェース（ＡＰＩ）２０１５によって影響されることが可能である。図１３の実施例にはＡＰＩは１つしか示されていないが、所望の機能を果たすために複数個のＡＰＩを構成できることが当業者には理解されよう。ある実施形態では、ＡＰＩは脅威および／またはトラフィック・パターンの何らかの変化を考慮して必要な度に、または所望に応じて修正可能である。ＡＰＩはアプリケーション層セキュリティ・サーバーならびに標準的な侵入検出ルール・フォーマットの代わりにメッセージ質問システムに基づく所有者フォーマットを使用するようにプログラムまたは適応化が可能である。

ある実施形態では、ルールおよび方針ＡＰＩの出力は自然言語であってよい。別の実施形態では、出力はそれらに限定されるものではないが、規則的表現、ＩＤＭＥＦのような侵入検出情報フォーマット、ＳＩＥＶＥのようなメール・フィルタリング、所有者ルール表現フォーマット、または当業者が適切であると見なすその他のフォーマットを含むルール表現言語であってよい。限定的ではない例として、示唆されたルールおよび方針でシステムをどのように構成するかを管理者またはユーザーに説明するために、自然言語出力を利用できる。

ＡＰＩはＴＭＣによって作成された最終的なルールの集合を改良するために利用できる。限定的ではない例として、あるメッセージ・セキュリティ・システムは所有者ルール・フォーマットを使用する質問エンジンを含んでいる。このようなシステムでは、“ｔｈｒｅａｔ．ｅｘｅ”添付を伴う着信メッセージをブロックするルールは下記のように規定できる。
添付フィルタリング・ルール：
方向：着信
添付：ｔｈｒｅａｔ．ｅｘｅ
アクション：メッセージを破棄
限定的ではない例として、このようなシステムでの“脅威タイトル”件名を有する着信メッセージをブロックするルールは下記のように規定できる。
メール監視ルール：
方向：双方向
フィールド：件名
データ：脅威タイトル
アクション：メッセージを破棄
異なる実施形態は異なる種類のフィルタリングを行うために異なる種類のルールを用いることができる。ルールおよび方針ＡＰＩ２０１５が用いられる場合は、ルールおよび方針作成モジュール２０２０がＡＰＩと通信するようにプログラムまたは適応化されなければならない。

ＴＭＣの出力２０１０は目標２０２５によって影響されることがある。目標２０２５はグローバル・目標、個々のメッセージング・セキュリティ・サーバー用の目標、または個々のユーザー用の目標であることができる。限定的ではない例として、あるＭＳＳはより保守的な脅威管理方針を有することができる。ある実施形態は自動的に整備されるルールを用いるように構成可能でき、一方、他の実施形態はローカル管理者によって認可されるルールを用いるように構成できる。ある状況では、不都合なコンテンツを破棄するルールを用いることが望ましく、別の状況ではそのコンテンツを隔離することが望ましいことがある。別の状況では、動作が行われる前に脅威の確率に対する信頼度が多少なりとも望ましいことがある。目標２０２５はグローバル目標でもよく、または異なるＭＳＳ用には別の目標でもよい例えば、スパム検出に９５％の有効率と９９．９％の精度を指定する目標をシステムに与えることができる。

ある実施形態では、別の目標として、システムによって１人以上のユーザー、ＭＳＳ、またはその他のエンティティが脅威のある通信を定義できるようにすることが可能である。限定的ではない例として、スパムの場合、スパムは良好に定義し得ないことがある。二分決定だけが可能であるのではなく、本発明はメッセージを異なるカテゴリーに分類できる（例えばビジネスｅ−メール、個人ｅ−メール、チェーン・メール、アダルト言語、ポルノ、ウエブ製品の提供、ニューズレター、メーリング・リストなど）。ある実施形態では、個々のユーザー、管理者、またはその他の適宜の人またはコンピュータ化されたユーザーがこれらの種類のコンテンツのいずれかの受信に関する好みを登録することができる。次にシステムはそのエンティティ用の方針を実施する。これは後述し、図１４に示されている脅威プッシュバック・システムで有用であり得る。

ルールおよび方針作成２０２０への入力は、それらに限定されるものではないが下記を含むことができる。
１．ＳｐａｍＡｒｃｈｉｖｅ．ｏｒｇのようなアーカイブからのスパムおよび非スパム・メッセージ、ユーザー報告スパム、個々のメッセージング・セキュリティ・システムによって識別されたスパム、分類ミスのメッセージに関する情報、分散チェックサム・クリアリングハウス（ｈｔｔｐ：／／ｗｗｗ．ｒｈｙｏｌｉｔｅ．ｃｏｍ／ａｎｔｉｓｐａｍ／ｄｃｃ）およびＲａｚｏｒ（ｈｔｔｐ：／／ｒａｚｏｒ．ｓｏｕｒｃｅｆｏｒｇｅ．ｎｅｔ）のような周知のスパム・データベースからの情報。
２．ウイルス定義ファイル、またはウイルス警報ニューズレター、および／またはウイルス警報データベースのような他のウイルス情報源からのウイルス情報。このシステムは形跡が得られる前にウイルス情報を生成するためにこの情報を利用できる。この情報は例えばアンチウイルス・メーカーであるＳｏｐｈｏｓおよびＭｃＡｆｅｅから入手可能である。この情報はＨＴＴＰ、ＦＴＰ、ＳＭＴＰを介して直接データベースにアクセスするか、他の適宜の手段で検索可能である。ある実施形態では、システムはウイルス定義ファイルが利用可能になる前にウイルスの蔓延をブロックし、ならびに他のアンチウイルス・システムが配備されていない場合の配備するためのルールを作成することができる。
３．侵入情報：この情報はバグトラック、ＣＥＲＴ、ソフトウエア・メーカー、オープン・ソースプロジェクト、ＦＢＩ ＩｎｆｒａＧａｒｄのような情報共用プロジェクト、または適宜のその他のソースから抽出可能である。この情報はさらに分散侵入検出システムから検索可能であり、またはユーザーによる手動入力も可能である。

システムは入力の種類およびソースに応じて入力のパージングおよび特徴抽出を行うことができる。スパン・メッセージの場合は、入力はマイクロソフトの．ｐｓｔフォーマット、ユニックスのｍｂｏｘフォーマット、転送されたスパムまたは添付ファイルとして送信されたスパム、スパム・メッセージのアーカイブ、またはその他のソースのような所有者フォーマットで記憶されているスパム・メッセージを含むことができる。スパム・メッセージはローカル記憶域、または、それらに限定されるものではないが、ＨＴＴＰ、ＳＣＰ、ＦＴＰ、ＰＯＰ、ＩＭＡＰ、またはＲＰＣのようなプロトコルを利用した遠隔記憶域からアクセス可能である。個々のメッセージについては、関連する特徴にはヘッダ、起点、およびメッセージ・コンテンツを含むことができる。各種の特徴は適宜に抽出し、記憶することができる。

好適な一実施形態はメッセージをパーズし、特徴を抽出するために規則的表現コンテンツ整合ツールを使用できる。コンテンツ整合のために利用される規則的な表現を定義するプリフィルタを使用できる。これが抽出される特徴の種類を決定する。限定的ではない例として、メッセージ件名を抽出するため、件名の行だけを吟味するｒｅｇｅｘフィルタを使用することができる。全てのヘッダに関する情報を抽出するために、メッセージのヘッダだけを観測するｒｅｇｅｘフィルタを使用できる。同様に、本体から異なる種類のコンテンツを抽出するために別のプリフィルタを使用することができる。通常のトークナイザ・プリフィルタが通常のコンテンツの特徴を供給することができる。これらの特徴は語、語句、ｎ−グラム、または当業者が有用であると見なす他の特徴であってよい。プリフィルタはあるｅ−メール・アドレスおよびドメイン名を無視することを含めて、ある種の語に敏感であることができる。プリフィルタはさらに、特徴をｅ−メール・アドレス、ＵＲＬ、電話番号などに集束させることもできる。

システムは敏感な特徴が確実に抽出されず、露出されないようにする匿名化モジュールを含むことができる。限定的ではない例として、匿名化モジュールはスパムの犠牲者およびドメインのＩＤを確定し、その情報の漏洩を防止することができる。

ウイルス警報用には、入力は新たなウイルスまたはウオームの存在とプロパティを説明するｅ−メール・メッセージであってよい。入力パーサはこれらのメッセージをパーズし、関連する脅威のプロパティを決定するように構成できる。これらのプロパティは、それらに限定されるものではないが、添付の名称または種類、件名の行、および発信アドレス（ｆｒｏｍ ａｄｄｒｅｓｓｅｓ）を含むことができる。入力パーサにはウイルス警報のソースが異なる場合は異なるフォーマット定義ファイル、またはプリフィルタを付与してもよい。あるいは、ウイルス警報パーサは他の情報にアクセスするためにウエブ・ページと通信することができる。この情報は関連するプロパティごとにパーズされることができる。別の実施形態では、ウイルス警報パーサはこのような情報を記憶するデータベースと直接インタラクトしてもよく、またはこのような情報に基づいてユーザーが手動的にデータをシステムに入力してもよい。

ルール作成システム２０２０は単一のシステムに常駐してもよく、または複数の工程が複数のシステムで実行されてもよい。脅威情報は正規の形式および抽出された関連の特徴に還元されることができる。システムは関連の特徴を確定し、および／または特徴の集合を還元するために多様なアルゴリズムを利用することができる。ある実施形態では、配置された各特徴をＭＳＳ上の質問システムに関連付けることができる。ＴＭＣは作成される適宜の種類のルールを決定することができる。ある実施形態では、複数の質問システムを利用して特徴を表現することができる。ある実施形態では、特徴の集合が還元され、有効な種類のルールを作成できる。

ある実施形態では、作成されたルールには重み付けがなされ、ある質問システムは特定のメッセージに関する全体的な脅威値にある程度の重みを有していてもよい。これらの値はシステムからの入力に基づいて決定することができる。したがって、これらの値は必要ならば、新たな脅威、ＭＳＳからのフィードバック、およびその他の適宜のソースに基づいて調整可能である。ＭＳＳは自動調整される重み、または各ルールおよび質問システムごとの信頼度、またはその他の関連情報に基づいて全体的な脅威の確率を判定するようにプログラム、または適応化可能である。好適な一実施形態では、ルール作成システム２０２０は新たな脅威情報を探すスケジューラを含むことができる。

システムは先ず候補になる１組のルール３０３０の集合を作成する。これらが配信される前に、システムはこれらのルールの妥当性を判定するために目標ベースのテスト２０３５を利用できる。

本発明のある実施形態はルールおよび方針をテストすることができる。テスト・データ２０４５は脅威データおよび非脅威データを含んでいてよい。システムはシステムの誤検出と見逃し、およびシステムの基本性能を発見するためにテスト・データの集合を利用することができる。ルール作成用に使用される目標２０４０はさらにテストへの入力として利用できる。性能上の目標を含むが、それに限定されない付加的な目標をテスト用に指定できる。指定された目標が達成されない場合は、システムは特徴の集合、個々の特徴の重み、各質問システムの重み、および目標に到達するための他のいずれかのパラメータを自動的に調整可能である。適切なチューニングが達成されると、ルールの集合が認可され、ＭＳＳに配信されることができる。
脅威プッシュバック・システム
公知のシステムの多くはローカルな環境の攻撃の兆候だけにしか対処しない。ＭＳＳのネットワークに加入している他のシステムを通知するほか、本発明のある実施形態は脅威の発生源を判定し、脅威を発生源の方向に押し戻すことができる。脅威の発生源が判定されると、システムはネットワークを経てメッセージを階層の他のシステムへと送信することができる。

脅威プッシュバック・システムはアプリケーション・クライアント、アプリケーション層セキュリティ・システム、またはＴＭＣの一部として、またはそれらを補うものとしてコンピュータ・システムに常駐することができる。脅威プッシュバック・システムの典型的なハードウエア構成には、アプリケーション層セキュリティ・システムに関して本明細書で前述したと同じ容量を有するシステム・プロセッサおよびシステム・データ・ストアが含まれている。典型的には、通信はインターネットのようなコンピュータ・ネットワークを介して行われることができる。しかし、直接接続およびダイアルアップ・アクセスを含む１つ以上の他の機構を利用することもできる。

図１４は脅威プッシュバック・システムの例を示している。２つの脅威認知モジュール３０３０，３０３５が示されている。脅威がローカルに検出されると３００５、脅威情報を脅威通知モジュール（ＴＮＭ）３０２０に送信可能である。ＴＮＭは脅威に関する情報を含む脅威通知３０４０を別のシステムの脅威検出モジュール３０２５に送ることができる。好適な実施形態では、ＭＳＳのＴＮＭは情報を別のＭＳＳに送ることができる。さらに別の実施形態では、クライアント・アプリケーション／システム、アプリケーション層セキュリティ・システムおよび／または脅威管理センター内の、またはこれらに接続されているようなネットワーク内のいずれかの位置にあるいずれかのＴＭＮは情報をネットワーク階層内の親に送ることができる。

脅威通知プロトコルは関与しているシステム全体で標準化することができる。ある実施形態は脅威通知情報に応答するようにプログラムされ、または適応化された脅威応答モジュール３０１５を含むことができる。

好適な実施形態では、本発明のシステムはアプリケーション層で機能するようにプログラムされ、または適応化されることができる。このような実施形態は容易に展開可能である。基礎になるネットワーク層プッシュバック・システムが動作している場合は、システムは脅威の経路を判定するためにその機能の一部を利用することができる。加えて、脅威通知システムは攻撃の発生源を判定することができる。限定されない例として、スパムの場合、攻撃発生源を判定するために、メッセージのヘッダを吟味しなければならない。システムはこれらのヘッダのうち幾つを信頼できるかを判定することができる。偽造されたヘッダを識別し、無視することができる。この工程はＩＰのレジスタのような外部データベース、およびＡＲＩＮのようなＡＳＮ番号、またはスパムハウスのようなスパム発生源のデータベースを参照することも含まれる。

アタッカーは通信で示される経路情報を偽造することができるので、システムは適正な経路を決定するために利用可能な情報を処理することができる。これはアプリケーション・レベル情報、ネットワーク情報、またはＩＰトレースバック・システムのような外部システムからの情報、および当業者には知られているその他の資源のいずれかの組み合わせで達成可能である。アプリケーション・レベルでは、アタッカーはある識別情報を偽造できることがある。経路決定モジュールは経路情報を通知送信者モジュールに提供することができる。経路決定モジュールは経路抽出サブモジュールおよび経路確認サブモジュールを含むことができる。

一実施形態では、経路抽出サブモジュールは識別情報をパーズし、これを経路情報として供給することができる。しかし、この情報は確認されておらず、不正確である場合がある。別の好適な実施形態では、経路確認モジュールは有効な経路情報を判定するために、抽出荒れた経路情報を処理することができる。限定的ではない例として、経路抽出サブモジュールはヘッダのようなメッセージ情報を読むことができる。戻り経路または受信ヘッダはメッセージが進行しタｅ−メール・サーバーの経路に関する情報を提供することができる。送信者のｅ−メール・アドレスを特定するために“ＦＲＯＭ（発信元）ヘッダを利用することができる。送信者のｅ−メール・アドレスを示すために“ＭＡＩＬ ＦＲＯＭ（メール発信元）”ＲＦＣ８２１のヘッダを利用できる。送信者のドメインまたはホストネームを示すために“ＥＨＬＯ”ＲＦＣ８２１のヘッダを利用できる。メッセージのＩＤおよびメッセージの実際のコンテンツを含む他のヘッダおよびメッセージの特徴を利用してもよい。アクションの要請情報は返答メール・アドレス、郵便の宛先、または電話番号のような、受信者用に提供される接触情報である。メッセージ内のこの情報を利用できる。それに限定されるものではないがネットワーク接続のＩＰアドレスを含む当業者には知られているその他の情報も利用できる。

情報の信憑性を判定するために幾つかの確認方法を利用できる。限定されない例として、上記のヘッダのほとんどは容易に偽造されるので、より信頼できるソースは戻り経路または受信ヘッダである。本発明の目標は可能な最長の本物の経路を判定することにある。本発明の一実施形態では、最後のヘッダだけが犠牲者のサーバーに接触した実際のサーバーであるので、このヘッダだけが使用される。受信された各ヘッダは受信元および受信者情報を含んでいる。これらの欄は適宜のＭＸレコード、Ａレコードおよび／またはリバースレコード、ならびに当業者に知られているその他の適宜のソースについてＤＮＳで確認することができる。これらのホストはオープンリレー・リスト、ダイアルアップ・アドレス・リストおよび判明しているスパム発生源リストについてチェック可能である。これらのリストのいずれかに存在することは正確に最後の受信ヘッダに関する付加的な情報を提供することができる。加えて、受信ヘッダの連鎖は互いに確認できる。この連鎖内での不一致によって、最後の正確な受信ヘッダに関する付加的な情報も得られる。これらのヘッダに関するその他の詳細は経路を確認するために利用できる。限定的ではない例として、日付情報およびサーバー・バージョン情報を利用できる。

プッシュバック・メッセージを特定方向に送出する必要があることをシステムが判定すると、システムはプッシュバック・メッセージにどの情報を含めるべきであるのかを決定することができる。本発明の脅威情報はソースのＩＰアドレスに加えて、脅威に関する詳細な追加情報を含んでいる。

詳細な脅威情報によってシステムは脅威に対してどのように反応するかに関するローカルな決定を下すことができる。限定的ではない例として、上記の脅威分類システムをスパム・メッセージの処理に利用できる。脅威プッシュバック・システムを介して送信されたスパム攻撃に関する情報は、脅威のカテゴリーおよびその他の関連する特性に関する情報を含むことができる。

受信システムは組織レベルで通信のある部分をブロックするように構成できる。さらに、ＩＰＳはこの情報を利用して、それに限定されるものではないが不正なメッセージを含むあるカテゴリーのスパム・メッセージをブロックすることができよう。組織がチェーンレターおよびアダルト言語をブロックする方針を有することができるようにシステムを構成可能である。デスクトップ・レベルで、付加的にニューズレターやメーリング・リストをブロックするように、個人がシステムを構成することができる。それによって、スパムの共通の定義を必要とせずに、ブロックされたデータをできるだけソースに近いように共通に定義することが可能になる。

脅威情報はその他のパラメータと共に脅威の存在を表示し、ソースを特定し、および／または詳細な脅威および／または応答情報を提供することができる。ソースを特定するため、提供される情報はそのＩＰアドレスまたはホストネーム、経路情報、判定された全経路情報のようなソースのＩＤを含むことができる。加えて、他のホストが独立して独自の抽出および／または確認を行うことができるように、経路情報を提供可能である。本発明のシステムはさらに、脅威であると判定されたトラフィックを表示して、経路上の受信者が記憶された情報から詳細を判定できるようにすることが可能である。本発明のこのシステムおよび方法はルーティング・システムで利用されるリバース・パス・フォワーディングの強化された形式である。
ホワイトリスト作成
一実施形態では、ホワイトリストに合致した通信は質問を受けないか、厳密な質問を受けないようにシステムを構成することができる。ホワイトリストが少なくとも１つのエントリを有すると、着信メッセージ質問システムがメッセージの質問と共にこのエントリを利用する。

図１０はエントリを追加するためにホワイトリスト上で実行可能な操作を示している。発信アドレスが上記のいずれかの除外条件をパスすると１００５、これはホワイトリストに追加できる。ホワイトリストはＳＤＳ上に記憶しておくことができる。システムは先ず、アドレスがリスト上に既に存在するか否かを確認するためにチェックする１０１０。存在する場合は、リストをいずれかの新規の情報で更新可能である１０１５。新規の情報が更新される前に、システムはＳＤＳ内に充分なスペースがあるか否かをチェックできる１０２５。充分なスペースを利用できない場合は、ＳＤＳから追加スペースが割り当てられる１０３０。ホワイトリストにアドレスが見つからない場合は、そのアドレスに初期のレコードを追加できる。ホワイトリストに新規のアドレスが追加される１０４０前に、システムはＳＤＳ内に充分なスペースがあるか否かをチェックできる１０２０。充分なスペースを利用できない場合は、ＳＤＳから追加スペースが割り当てられる１０３５。多くの実施形態で、明示的なスペースの割り当てが行われる必要はなく、むしろ情報の更新１０１５、またはエントリの追加１０４０の結果、暗黙的なスペースの割り当てが行われる。

アウトバウンド・アドレス用の初期レコードはｅ−メール・アドレス、内部ｅ−メール・アドレス、メッセージ送信時間、利用回数カウント、最終利用時間および／または関連がある、または有用であると当業者がみなしたその他のいずれかの特性を含むことができる。ホワイトリスト上に既に存在するｅ−メール・アドレスの場合、システムは合うとバウンド・アドレスとして利用されているｅ−メール・アドレスの各々のインスタンスごとに別個のレコードを利用することができ、またはシステムは利用のインスタンスを記述する情報を含め、そのエントリ内の情報の一覧と共に各アウトバウンド・アドレスごとに単一のレコードを保存することができる。システムは、異なるデータ構造を利用した他の多くの方法でレコードを記憶することができる。レコードはｅ−メール・アドレスに加えて、それに限定されるものではないがｅ−メール・アドレスのハッシュを含む他のデータ表現を含んでいてもよい。

好適な実施形態では、システムはレコードをＭｙＳＱＬデータベースに記憶することができる。限定的ではない例として、外部および内部のｅ−メール・アドレス、最後の更新日、出現カウンタから構成されたデータベースを構築するために下記のコマンドを使用できる。
Create table ctwhitelist
(out emailaddress 可変長（２５５）非ゼロ −外部ｅ−メール・アドレス
in emailaddress 可変長（２５５）非ゼロ −内部ｅ−メール・アドレス
lastupdatetime 日時 −このアドレスの最終更新
occr count 整数 −アドレス出現カウンタ
ホワイトリストの保存
ある実施形態では、システムによって無制限の記憶が可能になる。別の実施形態ではリスト用に利用できる記憶装置を制限することができる。さらに別の実施形態では、システムによってリストのサイズ管理が可能になる。それに限定されるものではないが、先入れ先出し法および最も長期間参照されていない方式（ＬＲＵ）を含む多くのキャッシング（ｃａｃｈｉｎｇ）技術を利用できる。その他の技術にはアウトバウンド・アドレスを報告した内部ユーザー数の感情を含むことができる。リストの一掃はリアルタイムで、または周期的に行うことができる。加えて、本発明によってホワイトリストを管理するために広範なリスト管理技術を利用できることが当業者には理解されよう。
ホワイトリストの利用
本発明によるホワイトリストを使用したシステムの例が図９に示されている。インバウンド通信９０５の１つ以上の関連パラメータが１つ以上のホワイトリスト９１０と比較される。ある実施形態では、ホワイトリストは着信した各ｅ−メール・メッセージごとにチェックされる。好適な実施形態では、比較には発信元アドレスが含まれる。ホワイトリスト９０１に対するチェックの結果、一致がないことが明らかになると、メッセージは通常のメッセージ質問９１５を受ける。通常のメッセージ質問は、前述のようにスパムまたはその他の脅威に最も敏感な分析基準を用いることができる。メッセージが通常の質問９１５にパスすると、すなわちそれがスパムでも脅威でもないこと（またはスパムまたは脅威である確率が低いこと）が判明すると、それは対象となる受信者に配信９２０用に提示されることができる。ホワイトリスト９１０に対するチェックの結果、一致が判明すると、多様な方法でメッセージを処理するようにシステムを構成できる。一実施形態では、どのメッセージ質問をも迂回して９２５、メッセージを対象となる受信者９２０に配信するようにシステムをプログラムまたはアレンジすることができる。代替実施形態では、適応性があるメッセージ質問９３０を利用してメッセージを処理するようにシステムをプログラムまたはアレンジすることができる。メッセージがスパムではないことを適応メッセージ質問９３０が判定すると、これはメッセージを配信９２０用に送出することができる。

ある実施形態では、双方のオプション９２５、９３０を選択的に利用できる。ホワイトリストに載せられた通信を適応メッセージ質問９３０にかけるのか、どのメッセージ質問９２５をも迂回するのかの決定は展開に応じて下すことができ、またはホワイトリスト・エントリの詳細に基づいて行うことができる。例えば、より頻繁に使用されるアウトバウンド・アドレスからのメッセージは質問を完全に迂回し９２５、一方、それほど頻繁に使用されていないアウトバウンド・アドレスからのメッセージは適応メッセージ質問９３０にかけることができる。

メッセージがホワイトリスト情報と共に通常の質問、または適応質問を通過すると、質問モジュールは質問の種類および／またはレベルを確定するためにホワイトリスト情報を利用することができる。好適な一実施形態では、適応メッセージ質問は図１１を参照してさらに記載するように、複数のレベルの信頼性を利用することができる。別の実施形態では、適応メッセージ質問は質問器が特徴として持っている信頼度を示す信頼度表示器をセットすることができる。

対象とされる受信者に配信されないメッセージは隔離または削除される。代替実施形態では、スパムであると判定されたメッセージはスパムまたは脅威であると表示され、対象とされる受信者に送出されることができる。

加えて、アウトバウンドされた各ｅ−メール・アドレスに信頼度の数値を割り当て可能である。所定の着信ｅ−メール・アドレスに関連する信頼度の値に応じて、着信メッセージに様々なレベルの質問を課すことができる。好適な一実施形態では、より低い信頼度の値に関連する着信メッセージにはより攻撃的なスパム質問が課され、より高い信頼度の値に関連する着信メッセージには攻撃性が低いスパム質問が課される。別の実施形態では、信頼度の値に基づくいずれかの負のスパム検出ポイントを相殺するために、メッセージに所定の正の信頼（ｐｏｓｉｔｉｖｅ ｃｒｅｄｉｔ）を与えることができる。

システムの好適な一実施形態によって外部ｅ−メール受信者の一部または全部をホワイトリスト９３５に載せることが可能になる。ある実施形態は特定のｅ−メール・アドレスへの発信メッセージ数を記述するメトリックを有することができる。メトリックがある閾値に達すると、ｅ−メール・アドレスはホワイトリストにリストされることができる。他の実施形態は時間を経てアドレスをトラッキングする能力を含むことができる。これらの実施形態では、特定の時間中にメトリックがアウトバウンドの特定のｅ−メール・アドレスの一定の値を超えると、そのエントリはホワイトリストにリストされることができる。

上記のパラメータは適宜のインターフェースを介してアプリケーション管理者によって構成可能であってよい。ある実施形態は固定されたパラメータをサポートすることがあるが、これらよりもアプリケーション管理者の構成が優先されてもよい。

ある実施形態では、スパムまたは脅威として特徴付ける閾値は、以前に受信された通信に関連するデータに基づいて動的に決定されてもよい。あるいは、個々のアドレスに関する特定の閾値を構成できるように、アプリケーション管理者にインターフェースを供給してもよい。ある実施形態では、アプリケーション管理者によって特別に構成されていない限り、デフォールトによる閾値を動的に導出してもよい。

スパムまたは脅威が検出されると、通知の代わりに、またはそれに加えて、１つ以上の応答手段をトリガすることができよう。このような応答手段は受信された通信のソースからのそれ以上の通信の受け入れ拒否、通信の隔離、通信が対象となる受信者に送出されるようにするための通信のストリッピング、および／またはあるソースからの過剰な数の着信通信の抑制を含むことができよう。
認証されたホワイトリスト
ホワイトリストに関する問題の１つは、アタッカーまたはスパム送信者がメッセージをホワイトリストにあるアドレスから送信したものと見せかけ、それによってフィルタリングおよびアンチスパム・ツールを迂回できることである。アタッカーがメッセージ上の送信者情報を偽造することは比較的容易である。ホワイトリストのこのような限界を克服するため、本発明のシステムによって送信者情報の認証が可能である。送信者認証をホワイトリスト・システムと統合するには幾つかの方法がある。一実施形態では、認証された送信者だけがホワイトリストにリストされることができる。このような手順は偽造された送信者がホワイトリストに載る確率を低下させることができる。しかし多くの環境では、認証されるメッセージの比率は低いので、ホワイトリスト作成の有効性が低下する。本発明のある実施形態によって、認証された送信者と認証されない送信者の双方がホワイトリストに載ることが可能になる。これらの実施形態では、認証された送信者からのメッセージにより高い信頼度の値が与えられる。ＳＭＩＭＥおよびＰＧＰは認証を与える機構を提供する。

このような実施形態の１つが図１１に示されている。限定されない例として、メッセージ１１０５がホワイトリスト１１１５上の送信者から受信されると、関連する信頼度のレベルが検索または計算される１１３５。ある実施形態では、信頼度のレベルは、単に再検索を必要とするだけのホワイトリスト・エントリに関連する単一の値である。別の実施形態では、信頼度レベルの値はエントリの様々な特徴の重み付の総計として計算可能である。このような実施形態のあるものでは、重みは静的に定義され、デフォールトでユーザーまたはその他のコンピュータ・システムによって無効にされるか、または動的に構成可能である。関連する信頼度レベルは閾値レベル１１４０と比較可能である。信頼度レベルの閾値と一致するか、それ以上の信頼度レベルを有する通信はいずれもメッセージ質問１１２０を迂回することができ、一方、充分なレベルの信頼度を有していない通信は少なくとも幾つかの質問１１２５で処理される。質問を迂回するメッセージ１１２０ならびに質問にパスしたメッセージ１１２５は対象となる受信者に配信されることができる１１４５。このような実施形態では、ホワイトリスト・エントリに関連しないメッセージには質問およびそれ以降の処理が課せられる１１５０。

本発明のある実施形態では信頼度レベルの閾値１１３０を管理者、システムの別のユーザー、または他のコンピュータ・システムによって構成可能である。
ホワイトリストからの除外条件
本発明によるスパム／脅威検出は全てのアウトバウンド・メッセージを吟味し、判明しているアウトバウンドのｅ−メール・アドレスのリストを保存する。結果として生じたリストは次に信頼できる送信者のリストとして利用可能である。しかし、全てのアウトバウンド・メッセージをあらゆる場合に着信メール用の信頼できる送信者リストに加えることは必ずしも推奨できないことがある。例えば、ユーザーがニュースグループにメッセージを送信することがあるが、それはこのニュースグループからのメッセージが必ずしもメール・フィルタリングを迂回することを示すものではない。さらに説明すると、ユーザーは配信解除メッセージをニューズレターに、またはスパム・メッセージに応答して送信することがある。このように、無条件のホワイトリスト追加を推奨できない状況があり得る。本発明のシステムによってある除外条件を入力出力、適用することが可能である。

これらの除外条件にはルール集合、経験則、人工知能、決定ツリー、またはそれらのいずれかの組み合わせが含まれる。条件は管理者、またはシステムの他のユーザーによって設定可能である。
電子通信の質問への多重待ち行列アプローチ
図７を参照すると、受信された通信に複数のリスク査定を行うための多重待ち行列アプローチが提示されている。

メッセージは先ず高度な処理および管理のための、ＳＤＳの一部である未処理メッセージ・ストア７３０に格納される。メッセージは外部ソース７４０から着信し、このストア７３０に格納される。このストア７３０は工程の終了までメッセージへの物理的制御を維持し、またはメッセージが質問基準をパスしない場合は、隔離される。

インデックスはメッセージ自体より大幅に小さいので、安定性と性能を高めるために、ストア７３０内でのメッセージへのインデックスは、実際のメッセージ自体の代わりに待ち行列層７２０内の各待ち行列７７１Ｂ、７８１Ｂ−７８４Ｂ、７９１Ｂを通過して質問エンジン７７１Ａ、７８１Ａ−７８４Ａ、７９１Ａへと送られるために使用される。

待ち行列および質問エンジンの双方とも、メッセージ上でアクションを行うために未処理メッセージのストア７３０内の実際のメッセージを再指示するためにインデックスを用いる。受信されたメッセージまたは通信にインデックスを割り当てるために、適宜の任意のインデックス割り当てアプローチを利用してよい。例えば最初に受信された通信の場合は０のような、ある定められたインデックスから始まる増分するインデックスを以前に受信された通信に割り当てりことによってインデックスの割り当てを行ってもよい。充分に大きいインデックスが割り当てられた後は、インデックスは定められた基点にリセットすることができよう。ある実施形態では、通信の種類、着信時間などのような受信された通信の特徴に基づいてインデックスが割り当てられてもよい。

このアプローチは複数の脅威にさらされた多重処理方式を利用してメッセージを独立的に処理し、それによって、複数の脅威にさらされた多重処理アプローチ電子通信大容量のメッセージを処理するスケーラブルな機構が得られる。

メッセージを独立して処理することによって、待ち行列層７２０は、既存の待ち行列上のメッセージにインデックスを付し、または新たな待ち行列を作成し、その待ち行列上のメッセージ上にインデックスを付すことによって最も効率的な処理手段を決定する。新たな待ち行列が作成される場合は、その新規の待ち行列に作用する特定の種類の質問エンジンが作成される。

待ち行列は拡張性および管理のために動的に追加、削除できる。好適な一実施形態では、アプリケーション管理者は起動時にシステムによって利用される元の数の待ち行列を構成することができる。管理者はさらに、性能および管理上の目的で特定の待ち行列、または特定種類の待ち行列を動的に削除または追加する能力を有している。各待ち行列は、複数の待ち行列および複数の処理工程が存在することができる特定の質問エンジンに関連している。

所有者アプリケーション特有のエンジンは、コンテンツのフィルタリング、ルールをベースにした方針遂行、および誤用防止などを行うために各待ち行列に作用することができる。緩やかに結合されたシステムによって、所有者アプリケーション特有のアプリケーションの機能強化を増強可能である。

この設計によって、メッセージ質問の適応された方法が提供される。アプリケーション特有エンジンは、コンテンツの質問を完遂するため未処理メッセージ・ストア内のメッセージへのインデックスを介してメッセージに作用する。

待ち行列の管理によって、アプリケーション管理者によるアクセスおよび管理を容易にするためにＷｅｂ、ｅ−メールのような適宜のインターフェースおよび／または前述のような電話をベースにしたインターフェースを介してメッセージの詳細が検索される。待ち行列の管理によって、管理者の特定のネットワークおよびシステム構成のニーズに最適になるようにシステムの特性をカスタマイズするため、管理者は（システム・デフォールト以外の）メッセージ待ち行列の順番を選択することができる。

図８Ａ−８Ｂは受信された通信に関連するリスク査定への多重待ち行列アプローチの利用を示した流れ図である。段階８０２で、工程の指導が開始されるか否かの決定が下される。そうである場合は、ＳＤＳから適宜の構成ファイルを読み出すために段階８０５および８０７が実行され、質問エンジンの種類、数、および順序が決定され、適宜の待ち行列およびインスタンスが作成される。否である場合は、工程は段階８１０で通信の受信を待機する。

段階８１２で受信すると、通信は未処理メッセージ・ストアと呼ばれるＳＤＳの部分に記憶される。通信には段階８１５で、未処理メッセージ・ストア内でその通信を一意的に識別するためのインデックスが割り当てられ、このインデックスは順序付けの制約に基づいて第一の待ち行列内に配される。

段階８１０で行われる通信の受信を待機する工程は、この工程のさらに別の段階とは関わりなく継続され、その結果、受信された各通信が流れ図の残りの部分を新たに横切ることが引き起こされる。ある実施形態では、段階８１０の複数のインスタンスが通信の受信を同時に待機してもよい。

ある実施形態では、追加の質問エンジンおよび関連する待ち行列を開始すべきであるか否を判定するため、通信の受信によって負荷の評価がトリガされてもよい。別の実施形態では、別個の工程がこの負荷分析を周期的および／またはアプリケーション管理者の指示によって行われてもよい。

インデックスは、段階８２５で判定された結果、待ち行列に関連する質問エンジンによって質問される準備ができるまで待ち行列８２０を移動する。この増分的な移動は質問の準備ができるまで段階８２０と８２５の間のループとして示されている。段階８２５で通信が評価される準備が完了していない場合は、その通信は段階８２０で待ち行列を通って移動し続ける。通信が準備完了である場合は、図８Ｂの段階８３０で適宜の質問エンジンにインデックスが付与される。

質問エンジンは段階８３０でそのインデックスに基づいて通信を処理する。段階８３５で質問が完了すると、質問エンジンは質問に基づいて受信された通信に関連する新規のリスク・プロファイルを作成する。

追加の質問が行われる場合は（段階８４０）、通信のインデックスは段階８４５で次の種類の質問のインスタンス用の待ち行列に配される。インデックスはこの次の待ち行列を移動すると、段階８２０での工程が続く。

これ以上の質問が要求されない場合は（段階８４０）、段階８５０で通信が全ての適宜のエンジンによる質問にパスしたか否かを判定するためのチェックがさらに行われる。通信が全ての質問にパスした場合は、通信は段階８５５で宛先へと送出され、段階８７０でこの通信の終了に関して処理される。

段階８５０での判定の結果、通信が１つ以上の質問に失敗した場合は、段階８６０で失敗時処理が行われる。適宜の失敗時処理が完了すると、段階８７０でこの通信の終了に関して処理される。

失敗時処理には多様な通知および／または修正手段を含めることができる。このような通知および／または修正手段は前述の、および以上検出に関連して下記に詳細に記載するような手段を含んでいてもよい。
異常検出工程
本発明の実施例による異常検出工程は図６に示すように３つの構成要素を使用する。
１．収集エンジン
これは実際のデータ収集が行われる所である。収集エンジンはアプリケーション・サーバーに向けられた、またはそこから発信された通信を受信する。受信された通信には１つ以上のテストが課される。これらの１つ以上のテストは上記の様々なリスク査定に対応するものでよい。

図６に示したような好適な一実施形態の収集エンジンは上記の多重待ち行列アプローチを利用する。しかし、この特定の収集エンジン・アーキテクチャは、この異常検出工程の文脈内で使用可能な収集エンジンに関して限定的であるのではなく、例示目的である。

図６に示されるように、収集エンジンは質問層６１０内の１種類以上の１つ以上の質問エンジンを含んでいる。待ち行列層６２０内の各種の質問エンジンには、関連する種類の質問エンジンによる質問を待機する受信された通信のインデックスを含む少なくとも１つのインデックス待ち行列が関連している。待ち行列６２０と質問層６１０とは全体として収集エンジンを形成する。受信された通信は受信され、ＳＤＳ内に記憶され、インデックスが付される。インデックスは収集エンジンミ夜処理を待ち行列内で待機する。
２．分析エンジン
以前の構成要素によって収集されたデータは以上検出エンジン６４０によって異常な活動について分析される。分析は以前受信された通信の分析から時間を経手累積されたデータに基づいて行われる。動的に導出された、または所定の閾値を用いて異常を検出するために１組の所定の経験則を利用してもよい。あらゆる種類のインターネット・アプリケーション通信用に多様な種類の異常を一般的に定義できるが、一方では、他の異常はｅ−メールまたはｗｅｂのような特定の種類のアプリケーション向けだけに定義できる。以前に受信された通信および適宜の構成データ６３０はＳＤＳに記憶される。

分析エンジンが検出する異常の種類の集合は、判明している種類の異常のより大きい集合から選択してもよい。対象となる集合はコンパイル時間に設定されてもよく、または実行時間に構成可能であり、またはある実施形態での実行中でもよい。設定アプローチを利用する実施形態では、あらゆる種類の異常および構成情報が分析エンジン内で設定される。このような実施形態のあるものでは、受信された通信の種類に応じて異なる異常の集合が対象になる。実行時間に構成可能な実施形態では、異常の種類が構成ファイルから読み出され、または分析エンジンの実行時間に対話式に構成される。設定アプローチの場合と同様に、ある種の異常性は選択された種類の通信に関してだけ対象となることができる。最後に、（ある設定または構成可能な実施形態を含む）ある実施形態では、上記のようなインターフェースが供給されて、分析エンジンの実行中に、対象となる種類の異常およびこれに関連するパラメータを再構成できるようにしてもよい。

様々な種類の異常の閾値は以前に受信された通信に関連するデータに基づいて動的に決定してもよい。あるいは、個々の種類の異常に関して特定の閾値を構成できるインターフェースをアプリケーション管理者に供給してもよい。ある実施形態では、デフォールトによる閾値はアプリケーション管理者によって特別に構成されない限り、動的に導出してもよい。

異常は典型的には特定の期間をベースにして検出される。このような期間は特定の固定期間（例えば先月、昨日、去年、セキュリティ・デバイスの最後の再起動以来など）であってよく、全ての種類の異常に適用される。あるいは、アプリケーション管理者によって上記のような適宜のインターフェースを介してあらゆる種類の異常性、または各種の異常性ごとに個別にそれぞれの期間を構成することもできる。ある実施形態はあらゆる種類の異常性、または各種の異常性ごとに個別に固定期間のデフォールトをサポートしてもよく、これはアプリケーション管理者の構成によって無効にされることができる。

好適な一実施形態では、図６に示すように、収集エンジンによって作成されたリスク・プロフィル６４２、６４４、６４６からの情報が、対象となる種類の異常の獲得された閾値と比較される。これらの比較に基づいて、受信された通信が異常であるか否かの判定がくだされ、異常である場合は、通信がどのように（異常の種類）異常であるかが判定される。

好適な一実施形態では、受信された通信に関連する記憶されたリスク・プロファイルが同じ種類の以前に受信された通信に関連するデータと統合される。次に、この新規の統合されたデータ集合が後続のその種類の受信された通信の分析に利用される。

異常が検出されると、異常表示信号が出力される。出力された信号は検出された異常の種類、および異常が検出された通信を特定する警報データ６５０のようなデータを含んでいてもよい。ｅ−メール・アプリケーション・セキュリティに関する様々な種類の異常を以下に記載する。これらの種類の異常は、以下に記載し、または前述の代替の異常検出アプローチのいずれかを利用して検出できる。
３．アクション・エンジン
分析に基づいて、この構成部品はどの種類のアクションがトリガされる必要があるかを決定する。一般に、アクションには進行中の異常な活動を管理者に警報することが含まれている。警報エンジン６６０はいずれかの適宜の通知を行い、および／またはいずれか適宜の修正アクションを開始することによってこのタスクを実行する。

出力された信号はある実施形態ではさらに別の応答をトリガする。あるいは、出力された信号が応答であってもよい。好適な一実施形態では、出力された信号は１つ以上のそれぞれ特定された配信プラットフォームを介して１人以上の指定の受信者に対する通知であってよい。例えば、通知はｅ−メール・メッセージ、ページ、ファクシミリ、ＳＮＭＰ警報、ＳＭＳメッセージ、ＷＡＰ警報、音声通話またはその他の適宜なメッセージで警告するＯＰＳＥＣ（オペレーション・セキュリティ）の形態のものでよい。あるいは、このような通知は出力された信号によってトリガされることもできよう。

通知の代わりに、または通知に加えて、出力された信号によって１つ以上の修正手段がトリガ可能であろう。このような修正手段には受信された通信のソースからのそれ以上の通信の受信拒否、通信の隔離、アプリケーション・サーバーによって安全に処理されるようにするための通信のストリッピング、および／または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによってメッセージング可能なレベルまで抑制することを含めることができよう。

好適な一実施形態では、アプリケーション管理者が所望の応答を選択的に構成でき、構成されたこの応答を特定の種類の異常と関連付けることによって、その種類の異常が検出されると、構成された応答が行われるようにするインターフェースを備えてもよい。

図４は本発明の好適な一実施形態による典型的な異常検出工程の流れ図を示す。工程は段階４１０で、異常の種類、これらの種類の閾値、および以前のデータが考慮されるべき期間を含む処理上の様々な制約を初期設定することによって開始される。この情報は初期設定段階で対話式に構成できる。対話式の構成に加えて、またはその代わりに、以前記憶された構成情報をＳＤＳからロードしてもよい。

工程は段階４２０で継続され、そこで異常定義情報（例えば１５分の期間内に同じ添付ファイルを有する着信メッセージ）が読み出される。次に、新たなスレッドが必要であるか否かが判定される。この判定は異常の詳細を読み込むこと（段階は示さず）に基づいて行われる。段階４３０で、新たなスレッドが必要な場合は、スレッドは段階４５０で処理されるように紡がれる（ｔｈｅ ｔｈｒｅａｄ ｉｓ ｓｐｕｎ）。段階４４０で、工程は異常に冠する情報を読み出すために段階４２０に戻るまで特定期間だけ休止する。

段階４５０で新規のスレッドの処理が開始されると、異常を評価するために必要な情報がＳＤＳ内の適宜の記憶域から検索され、必要ならば操作され、段階４６０で分析される。段階４７０での判定は異常を検出するために行われる。好適な一実施形態では、この段階は判定を下すために所定の閾値を用いる。このような所定の閾値は対話式に、または構成ファイルを介して供給されることができよう。以上が検出されない場合は、工程は停止される。

異常が検出されると段階４８０で異常表示信号が出力され、その結果、通知がなされてもよい。可能性がある異常検出の結果はアクション・エンジンに関連して上記に詳細に記載されている。

異常の種類は特定のアプリケーション・サーバーの種類と性質によって変化することがある。以下の記述はｅ−メールが問題のアプリケーション文脈である、異常の定義例を示す。これらに類似する、または同一の異常は別の種類のアプリケーション・サーバーに対して定義可能である。

ｅ−メール・システムには潜在的に多くの種類の異常がある。分析は収集されたデータ、および経験則で監査されたデータに基づく正常さについての動的なルールに基づいて行われる。ある実施形態では、アプリケーション管理者に対して、異なる種類の異常性に対する所定のルールを構成するためのインターフェースを供給することができる。図５はこのようなインターフェース用のサンプル・スクリーンを示している。インターフェースの機能はセキュリティ強化デバイス上で動作するＷｅｂサーバー、または前述のような適宜のインターフェース・プラットフォームを介して供給されることができる。

好適な一実施形態では、各分析用の閾値は異常アクション・テーブルから導出される。各異常ごとのアクションもこのテーブルから取り出される。分析は何らかの異常が発生したことを特定し、アクション・モジュールに委託する。ｅ−メールに関して様々な種類の異常を下記に列挙する。

１．同じＩＰアドレスからのメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージの発信元であるＩＰアドレスに関する情報を有している。ＩＰアドレスはＳＤＳ内に記憶される。この異常の判定基準は、所定期間で同じＩＰアドレスからのメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

２．同じアドレス（ＭＡＩＬ ＦＲＯＭ）からのメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージの発信元であるアドレス（ＭＡＩＬ ＦＲＯＭ）に関する情報を有している。判定されたアドレスはＳＤＳ内に記憶される。この異常の判定基準は、所定期間で同じＭＡＩＬ ＦＲＯＭアドレスからのメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

３．同じサイズを有するメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージのサイズに関する情報を有している。メッセージのサイズはＳＤＳに記憶される。このサイズはメッセージ本体のサイズのことであり、ヘッダのサイズは含まれない。この異常の判定基準は、所定期間で同じサイズのメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

４．同じ件名を有するメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージの件名の行に関する情報を有している。メッセージの件名行の情報はＳＤＳに記憶される。この異常の判定基準は、所定期間で同じ件名行を有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

５．同じ添付名を有するメッセージ−この異常の収集ポイントはＭＩＭＥ Ｒｉｐｐｅｒ待ち行列である。ＭＩＭＥ Ｒｉｐｐｅｒ待ち行列は実際のメッセージを構成要素のＭＩＭＥ部分へとパーズし、この情報をＳＤＳに記憶する。この情報の一部は添付ファイル名である。この異常の判定基準は、所定期間で同じ添付名を有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

６．同じ添付拡張を有するメッセージ−同じ添付名を有するメッセージ−この異常の収集ポイントはＭＩＭＥ Ｒｉｐｐｅｒ待ち行列である。ＭＩＭＥ Ｒｉｐｐｅｒ待ち行列は実際のメッセージを構成要素のＭＩＭＥ部分へとパーズし、この情報をＳＤＳに記憶する。この情報の一部は添付ファイル拡張である。この異常の判定基準は、所定期間で同じ拡張を有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

７．ウイルスを有するメッセージ−この異常はいずれかのアンチウイルス待ち行列がイネーブルされた場合だけ検出される。この異常の収集ポイントはアンチウイルス待ち行列である。アンチウイルス待ち行列はメッセージの個々のＭＩＭＥ部分上のいずれかのウイルスを走査する。走査の詳細はＳＤＳに記憶される。この異常の判定基準は、所定期間でウイルスを有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

８．同じウイルスを有するメッセージ−この異常はいずれかのアンチウイルス待ち行列がイネーブルされた場合だけ検出される。この異常の収集ポイントはアンチウイルス待ち行列である。アンチウイルス待ち行列はメッセージの個々のＭＩＭＥ部分上のいずれかのウイルスを走査する。走査の詳細はＳＤＳに入力される。この情報の一部はウイルス名である。この異常の判定基準は、所定期間で同じウイルスを有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。

下記の表はこの情報をＳＤＳに記憶するためにリレーショナル・データベースを利用した好適な一実施形態の異常テーブルの欄を示している。

下記の表はこの情報をＳＤＳに記憶するためにリレーショナル・データベースを利用した好適な一実施形態の異常アクション・テーブルの欄を示している。

本件出願を通して、様々な刊行物が参照された。これらの刊行物の開示内容は本発明が関与する技術水準をより充分に記載するために全体が参照によって本明細書に組み込まれている。

上記の実施形態は例示目的のみで開示されたものである。本発明から離れることなく、本明細書に開示された特定の実施形態に多くの変更が可能であることが当業者には容易に理解されよう。したがって、本発明の範囲は上記に記載の特定の実施形態に限定されるものではなく、下記の特許請求の範囲によって決定されるべきものである。

本明細書に組み込まれ、その一部を構成する添付図面は、本発明の実施形態を図示し、記載内容と共に本発明の原理を説明する役割を果たす。
図１は典型的な従来技術のアクセス環境を示す。 図２は本発明による好適な一実施形態を用いた環境のハードウエア図を示す。 図３は本発明の典型的な実施形態の構成要素の論理構成図である。 図４は本発明による異常検出工程の例の流れ図である。 図５は異常検出構造インターフェース・スクリーンのサンプルである。 図６は本発明による請求項強化システムの実施例のアーキテクチャを示す構成図である。 図７は受信された通信に対する複数のリスク査定のアプリケーションを管理するために複数の待ち行列を利用した、本発明によるリスク査定の実施例のアーキテクチャを示す構成図である。 図８Ａは図７に示したアーキテクチャを用いた、受信された通信に関連するリスク査定工程を示す流れ図である。 図８Ｂは図７に示したアーキテクチャを用いた、受信された通信に関連するリスク査定工程を示す流れ図である。 図９は本発明による通信査定工程の実施例の流れ図である。 図１０は本発明によるホワイトリスト管理工程の流れ図である。 図１１は本発明による質問工程の実施例の流れ図である。 図１２は脅威管理アーキテクチャの好適な実施形態を通る情報の流れの概要を示す。 図１３は本発明による好適な一実施形態を用いた脅威管理センター（ＴＭＣ）の構成図を示す。 図１４は本発明による好適な一実施形態を用いた脅威プッシュバック・システムの実施例を示す。 図１５は本発明による典型的な個人メッセージング・セキュリティ・システム（またはアプリケーション層セキュリティ・システム）の構成要素を示す。 図１６は本発明によるセキュア配信工程の実施例の流れ図である。 図１７は本発明によるセキュア配信工程の実施例の別の流れ図である。

Claims (42)

1. ａ）１つ以上のアプリケーション・サーバー・システムと通信するように構成された少なくとも１つのアプリケーション・サーバー・システム通信インターフェースと、
   ｂ）電子通信および受信された電子通信に関連する累積データを記憶可能であるシステム・データ・ストアと、
   ｃ）前記システム・データ・ストアおよび前記少なくとも１つのアプリケーション・サーバー・システム通信インターフェースと通信するシステム・プロセッサと
   を含むアプリケーション層セキュリティ・システムであって、
   前記システム・プロセッサは、
   ｉ）遠隔のシステムからの電子通信、選択されたアプリケーション・サーバー・システムに向けられた電子通信または前記選択されたアプリケーション・サーバー・システムからの電子通信を受信し、
   ｉｉ）前記受信された電子通信に複数のテストを課し、前記複数のテストは、複数のセキュリティ・リスク・カテゴリに対して前記受信された電子通信を評価するために結合し、前記複数のテストの各々は、前記複数のセキュリティ・リスク・カテゴリのうちの少なくとも１つに対してテストするように動作可能であり、
   ｉｉｉ）前記課せられた複数のテストに基づいて、前記受信された電子通信に関連するリスク・プロファイルを前記システム・データ・ストアに記憶し、前記リスク・プロファイルは、前記電子通信に課せられた前記複数のテストの各々の結果を含むアレイを含み、
   ｉｖ）前記記憶されたリスク・プロファイルと、前記システム・データ・ストアからの前記受信された電子通信に関連する累積データとに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定し、
   ｖ）異常の存在が判定されると異常表示信号を出力する、システム。
2. 前記受信された電子通信は、ｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む、請求項１に記載のシステム。
3. 前記受信された電子通信は、ｅ−メール通信である、請求項２に記載のシステム。
4. 前記システム・プロセッサによって課せられる前記複数のテストの各々は、侵入検出、ウイルス検出、スパム検出、または、方針違反検出を含む、請求項１に記載のシステム。
5. 前記システム・プロセッサは、前記複数のテストの各々を順次に課す、請求項１に記載のシステム。
6. 前記システム・データ・ストアは、
   ｉ）電子通信を記憶可能なメッセージ・データ・ストアと、
   ｉｉ）複数のインデックス待ち行列を記憶可能な待ち行列データ・ストアと
   を含み、
   前記システム・プロセッサは、
   １）前記受信された電子通信を前記メッセージ・データ・ストアに記憶することと、
   ２）前記記憶された電子通信に選択されたインデックスを割り当てることと、
   ３）複数のテスト・エンジンを実行することであって、前記複数のテスト・エンジンの各々は、テストの種類を有し、前記複数のテスト・エンジンの各々は、前記待ち行列データ・ストア内に、前記複数のテスト・エンジンの各々に関連するインデックス待ち行列を有し、前記複数のテスト実行エンジンのうち少なくとも２つは、任意の所与の時点において、互いに異なる複数のテストの種類を有し、前記複数のテスト・エンジンの各々は、 （ａ）付されたインデックスに対してそれに関連する前記インデックス待ち行列を監視し、 （ｂ）前記メッセージ・データ・ストアから前記付されたインデックスに関連する前記電子通信を検索し、（ｃ）前記検索された電子通信を１つ以上の判断基準の集合についてテストする、ことと、
   ４）前記選択されたインデックスを、第１のテスト・エンジンに関連する前記インデックス待ち行列に配置することであって、前記第１のテスト・エンジンは、第１のテストの種類を有する、ことと、
   ５）前記選択されたインデックスに関連する前記記憶された電子通信に対して前記第１のテスト・エンジンがテストを行った後に、前記選択されたアプリケーションインデックスを第２のテスト・エンジンに関連する前記インデックス待ち行列に配置することであって、前記第２のテスト・エンジンは、前記第１のテストの種類とは異なる第２のテストの種類を有する、ことと
   を行うことによって前記複数のテストを順次に課す、請求項５に記載のシステム。
7. 各テスト実行エンジンのテストの種類は、侵入検出、ウイルス検出、スパム検出、または、方針違反検出である、請求項６に記載のシステム。
8. 前記システム・プロセッサは、前記システム・データ・ストアに記憶されている構成情報にさらに基づいて、異常が存在するか否かを判定し、前記構成情報は、異常の種類、異常閾値情報、異常期間情報、または、異常応答情報を含む、請求項１に記載のシステム。
9. 前記システム・プロセッサは、さらに、受信された電子通信に関連する前記システム・データ・ストア内の前記累積データから１つ以上の異常閾値を導出する、請求項１に記載のシステム。
10. 前記システム・プロセッサは、
    １）対象となる異常の種類の集合を決定し、
    ２）前記決定された対象となる異常の種類ごとに、
    （ａ）前記システム・データ・ストアからの受信された電子通信に関連する累積データに少なくとも部分的に基づいて、それぞれの異常の種類に関連する１つ以上の異常閾値を獲得することと、
    （ｂ）前記記憶されたリスク・プロファイル内の情報を前記獲得された１つ以上の異常閾値と比較することと、
    （ｃ）前記比較に基づいて前記受信された電子通信に関して前記それぞれの異常の種類のうちの異常が存在するか否かを判定することと
    によって、異常が存在するか否かを判定する、請求項１に記載のシステム。
11. 前記システム・プロセッサは、前記受信された電子通信に基づいて前記対象となる異常の種類の集合を決定する、請求項１０に記載のシステム。
12. 前記異常表示信号は、管理者に伝達される通知を含む、請求項１に記載のシステム。
13. 前記異常表示信号は、異常の種類を含む、請求項１に記載のシステム。
14. 前記システムは、ファイアウォール・システムと１つ以上のアプリケーション・サーバー・システムとの間に配置されている、請求項１に記載のシステム。
15. 前記ファイアウォール・システムと通信するように構成されたファイアウォール通信インターフェースをさらに含み、
    前記システム・プロセッサは、前記選択されたアプリケーション・サーバー・システムに向けられた電子通信を前記ファイアウォール通信インターフェースを介して受信する、請求項１４に記載のシステム。
16. 前記システム・プロセッサは、さらに、前記受信された電子通信を、前記受信された電子通信によって指示された宛先に送出する、請求項１に記載のシステム。
17. 前記システム・プロセッサは、さらに、前記記憶されたリスク・プロファイルを前記受信された電子通信に関連する前記累積データと統合して、前記統合されたデータを前記システム・データ・ストア内に記憶する、請求項１に記載のシステム。
18. 前記システム・プロセッサは、さらに、前記受信された通信に課せられるテストを決定する、請求項１に記載のシステム。
19. 前記システム・プロセッサは、前記受信された電子通信の特徴に基づいて課せられるテストを決定する、請求項１８に記載のシステム。
20. 前記システム・プロセッサは、記憶された構成情報に基づいて前記１つ以上のテストを課し、前記記憶された構成情報は、異常の種類、異常閾値情報、異常期間情報、または、異常応答情報を含む、請求項１に記載のシステム。
21. 前記システム・プロセッサは、さらに、前記異常表示信号に応答する修正手段を講じる、請求項１に記載のシステム。
22. 前記修正手段は、
    前記受信された通信のソースからのそれ以上の通信の受け取りを拒否すること、
    前記受信された通信を隔離することと、
    前記受信された通信から特定されたコンテンツを剥ぎ取ること（ｓｔｒｉｐｐｉｎｇ）、または
    毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによって管理可能なレベルまで抑制すること
    を含む、請求項２１に記載のシステム。
23. 前記１つ以上のアプリケーション・サーバー・システムは、ｅ−メール・サーバー・システム、Ｗｅｂサーバー・システム、ＦＴＰサーバー・システム、テルネット・サーバー・システム、ＧＯＰＨＥＲサーバー・システム、または、ＷＡＩＳサーバー・システムを含む、請求項１に記載のシステム。
24. アプリケーション層通信セキュリティを強化する方法であって、前記方法は、企業通信システムのハードウェア・デバイスにおいて実行され、
    前記方法は、
    ａ）選択されたアプリケーション・サーバー・システムに向けられた電子通信、または前記選択されたアプリケーション・サーバー・システムからの電子通信を受信するステップであって、前記受信された電子通信は、アプリケーション層通信であり、システム・データ・ストアに記憶される、ステップと、
    ｂ）前記受信された電子通信に複数のテストを課すステップであって、前記複数のテストは、複数のセキュリティ・リスク・カテゴリに対して前記受信された電子通信を評価し、前記複数のテストの各々は、前記複数のセキュリティ・リスク・カテゴリのうちの少なくとも１つに対してテストするように動作可能であり、これにより、前記電子通信に関連する少なくとも１つのリスク・プロファイルを作成し、前記課せられた複数のテストに基づいて、前記受信された電子通信に関連するリスク・プロファイルを前記システム・データ・ストアに記憶し、前記リスクプロファイルは、前記受信された電子通信に課せられた前記複数のテストの各々の結果を含むアレイを含む、ステップと、
    ｃ）前記少なくとも１つのリスク・プロファイルに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定するステップと、
    ｄ）異常の存在が判定されると異常表示信号を出力するステップと
    を含む、方法。
25. 前記受信された電子通信は、ｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、または、ゴーファー通信を含む、請求項２４に記載の方法。
26. 前記受信された電子通信は、ｅ−メール通信である、請求項２５に記載の方法。
27. 前記複数のテストを課すステップは、侵入検出テスト、ウイルス検出テスト、スパム検出テスト、または、方針違反テストのうちの１つ以上を課すことを含む、請求項２４に記載の方法。
28. 前記複数のテストを課すステップは、前記複数のテストの各々に対して、
    ｉ）実施されるテストを選択するステップと、
    ｉｉ）前記受信された電子通信で前記選択されたテストを実施するステップと、
    ｉｉｉ）前記実施されたテストに基づいてリスク・プロファイルを出力するステップと
    を実行することを含む、請求項２４に記載の方法。
29. 前記テストを選択するステップは、前記受信された電子通信に関連する種類に基づいてテストを選択することを含む、請求項２８に記載の方法。
30. 構成情報を受信するステップをさらに含み、
    異常が存在するか否かを判定するステップは、前記受信された構成情報にさらに基づいており、前記受信された構成情報は、異常の種類、または、異常応答情報を含む、請求項２４に記載の方法。
31. 受信された通信に関連する累積データを受信するステップをさらに含み、
    前記異常が存在するか否かを判定するステップは、前記受信された累積データから異常閾値情報を導出することを含む、請求項３０に記載の方法。
32. 前記受信された構成情報は、異常閾値情報または異常期間情報をさらに含む、請求項３０に記載の方法。
33. 受信された通信に関連する累積データを受信するステップをさらに含み、
    前記異常が存在するか否かを判定するステップは、前記受信された通信に関連する受信された累積データにさらに基づいている、請求項２４に記載の方法。
34. 前記異常表示信号に応答する修正手段を講じるステップをさらに含み、
    前記修正手段は、
    前記受信された通信のソースからのそれ以上の通信の受け取りを拒否することと、
    前記受信された通信を隔離することと、
    前記受信された通信から特定されたコンテンツを剥ぎ取ること、または
    毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによって管理可能なレベルまで抑制すること
    を含む、請求項２４に記載の方法。
35. システム・プロセッサによって実行されると、アプリケーション層セキュリティを提供することを前記システム・プロセッサに行わせる命令を記憶するコンピュータ読み出し可能な媒体であって、前記媒体には、
    ａ）選択されたアプリケーション・サーバー・システムに向けられた電子通信、または前記選択されたアプリケーション・サーバー・システムからの電子通信を受信するステップであって、前記受信された電子通信は、アプリケーション層通信である、ステップと、
    ｂ）前記受信された電子通信に複数のテストを課すステップであって、前記複数のテストは、複数のセキュリティ・リスク・カテゴリに対して前記受信された電子通信を評価し、前記複数のテストの各々は、前記複数のセキュリティ・リスク・カテゴリのうちの少なくとも１つに対してテストをするように動作可能であり、これにより、前記電子通信に関連する少なくとも１つのリスク・プロファイルを作成し、前記課せられた複数のテストに基づいて前記受信された電子通信に関連するリスク・プロファイルを前記システム・データ・ストアに記憶し、前記リスク・プロファイルは、前記受信された電子通信に課せられた前記複数のテストの各々の結果を含むアレイを含む、ステップと、
    ｃ）前記少なくとも１つのリスク・プロファイルに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定するステップと、
    ｄ）異常の存在が判定されると異常表示信号を出力するステップと
    を前記システム・プロセッサに実行させる命令が記憶されている、媒体。
36. 前記電子通信を受信することを前記システム・プロセッサに行わせる前記命令は、ｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、または、ゴーファー通信を受信することを前記システム・プロセッサに行わせる命令を含む、請求項３５に記載の媒体。
37. 前記電子通信を受信することを前記システム・プロセッサに行わせる前記命令は、ｅ−メール通信を受信することを前記システム・プロセッサに行わせる命令を含む、請求項３５に記載の媒体。
38. 前記電子通信を受信することを前記システム・プロセッサに行わせる前記命令は、侵入検出テスト、ウイルス検出テスト、スパム検出テスト、または、方針違反テストの１つ以上を課すことを前記システム・プロセッサに行わせる命令を含む、請求項３５に記載の媒体。
39. 複数のテストを課すように前記システム・プロセッサに行わせる前記命令は、
    ｉ）実施されるテストを選択することと、
    ｉｉ）前記受信された電子通信で前記選択されたテストを実施することと、
    ｉｉｉ）前記実施されたテストに基づいてリスク・プロファイルを出力することと
    を前記システム・プロセッサに行わせる命令を含む、請求項３５に記載の媒体。
40. 異常が存在するか否かを判定することを前記システム・プロセッサに行わせる前記命令は、
    ｉ）対象となる異常の種類の集合を決定することと、
    ｉｉ）前記決定された集合における対象となる異常の種類ごとに、
    １）それぞれの異常の種類に関連する１つ以上の異常閾値を獲得することと、
    ２）前記少なくとも１つのリスク・プロファイル内の情報を前記獲得された１つ以上の異常閾値と比較することと、
    ３）前記比較に基づいて前記受信された電子通信に関して前記それぞれの異常の種類のうちの異常が存在するか否かを判定することと
    を前記システム・プロセッサに行わせる命令を含む、請求項３５に記載の媒体。
41. 前記異常表示信号を出力するように前記システム・プロセッサに行わせる前記命令は、管理者に通知を伝達することを前記システムに行わせる命令を含み、前記通知は、ｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、または、ＳＮＭＰ警報を含む、請求項３５に記載の媒体。
42. ａ）アプリケーション層電子通信を受信する受信手段と、
    ｂ）電子通信と、受信された電子通信に関連する累積データとを記憶する記憶手段と、
    ｃ）複数のテストを前記受信された電子通信に課す査定手段であって、前記複数のテストは、複数のセキュリティ・リスク・カテゴリに対して前記受信された電子通信を評価し、前記複数のテストの各々は、前記複数のセキュリティ・リスク・カテゴリのうちの特定のセキュリティ・リスク・カテゴリに対してテストするように動作可能であり、前記査定手段は、前記記憶手段にリスク・プロファイルを記憶し、前記リスク・プロファイルは、前記複数のテストを前記受信された電子通信に課すことによって作成されたものであり、前記リスク・プロファイルは、前記電子通信に課せられた前記複数のテストの各々の結果を含むアレイを含む、査定手段と、
    ｄ）前記記憶手段内の前記リスク・プロファイルと、前記受信された電子通信に関連する累積データとに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定する異常判定手段と、
    ｅ）前記異常判定手段によって異常が存在することが判定されると、異常表示信号を出力する出力手段と
    を含むアプリケーション層セキュリティ・システム。

Images