(57)【要約】電子セキュリティ（１９０）を強化するシステムおよび方法が提供される。アプリケーション（１２０）に関連する電子通信が受信され、記憶される。受信された通信に関する１つ以上のリスク・アセスメントがなされることによって、その通信に関連するリスク・プロファイルが作成される。リスク・プロファイルは以前に受信した通信に関連するデータ（２１０）に関して分析されて、受信した通信に異常がないか否かが判定される。受信された通信に異常があると判定された場合は異常表示信号が出力される。
2005520230.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション層セキュリティ・システムであって、
ａ）前記セキュリティ・システムを１つ以上のアプリケーション・サーバー・システムに通信可能に結合する少なくとも１つのアプリケーション・サーバー・システムと、
ｂ）電子通信および受信された電子通信に関連する累積データを記憶可能であるシステム・データ・ストアと、
ｃ）前記システム・データ・ストアおよび前記少なくとも１つのアプリケーション・サーバー・システム通信インターフェースと通信するシステム・プロセッサとを備え、前記システム・プロセッサは１つ以上の処理要素を備えると共に、前記システム・プロセッサは、
ｉ）選択されたアプリケーション・サーバー・システムに向けられた、またはそこからの電子通信を受信し、
ｉｉ）前記受信された電子通信に１つ以上のテストを課し、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された電子通信を評価し、
ｉｉｉ）課せられる１つ以上のテストに基づいて、前記受信された電子通信に関連するリスク・プロファイルをシステム・データ・ストアに記憶し、
ｉｖ）前記記憶されたリスク・プロファイルおよび受信された電子通信に関連する前記システム・データ・ストアからの累積データに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定し、
ｖ）異常の存在が判定されると異常表示信号を出力する、
システム。
【請求項２】
前記受信された電子通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む請求項１に記載のシステム。
【請求項３】
前記受信された電子通信はｅ−メール通信である請求項２に記載のシステム。
【請求項４】
前記システム・プロセッサによって課せられる１つ以上のテストは各々、侵入検出、ウイルス検出、スパム検出、または方針違反検出を含む請求項１に記載のシステム。
【請求項５】
前記システム・プロセッサは複数のテストを課す請求項１に記載のシステム。
【請求項６】
前記システム・プロセッサは前記複数のテストの各々を並行して課す請求項５に記載のシステム。
【請求項７】
前記システム・プロセッサは前記複数のテストの各々を順次に課す請求項５に記載のシステム。
【請求項８】
前記システム・データ・ストアは、
ｉ）電子通信を記憶可能なメッセージ・データ・ストアと、
ｉｉ）複数のインデックス待ち行列を記憶可能な待ち行列データ・ストアとを備え、
前記システム・プロセッサは複数のテストを順次、
１）前記受信された電子通信を前記メッセージ・データ・ストアに記憶し、
２）前記記憶された電子通信に選択されたインデックスを割り当て、
３）複数のテスト・エンジンを実行することによって課し、前記各テスト・エンジンはテストの種類を有し、関連する待ち行列データ・ストア内にインデックス待ち行列を有し、任意の所定の時点にテスト実行エンジンのうち少なくとも２つは異なるテストの種類を有し、各テスト・エンジンは、
（ａ）付されたインデックスにつて関連するインデックス待ち行列を監視し、
（ｂ）前記メッセージ・データ・ストアから前記付されたインデックスに関連する前記電子通信を検索し、
（ｃ）前記検索された電子通信を１つ以上の判断基準の集合についてテストし、かつ、
４）前記選択されたインデックスを、第一の種類のテストを有する第一テスト・エンジンに関連するインデックス待ち行列へと配し、
５）前記選択されたインデックスに関連する前記記憶された電子通信に対して前記第一テスト・エンジンがテストを行った後、前記選択されアプリケーションインデックスを第二テスト・エンジンに関連するインデックス待ち行列へと配し、前記第二テスト・エンジンは前記第一のテストの種類とは異なる第二のテストの種類を有している請求項７に記載のシステム。
【請求項９】
前記各テスト実行エンジンは侵入検出、ウイルス検出、スパム検出、または方針違反検出である請求項８に記載のシステム。
【請求項１０】
前記システム・プロセッサは前記システム・データ・ストアに記憶されている構成情報に基づいて前記１つ以上のテストの各々を課す請求項１に記載のシステム。
【請求項１１】
前記システム・プロセッサはさらに、前記システム・データ・ストアに記憶されている構成情報に基づいて異常が存在するか否かを判定する請求項１に記載のシステム。
【請求項１２】
前記構成情報は異常の種類、異常の閾値情報、異常の期間情報、または異常応答情報を含む請求項１１に記載のシステム。
【請求項１３】
前記システム・プロセッサはさらに受信された電子通信に関連する前記システム・データ・ストア内の前記累積データから１つ以上の異常閾値を導出する請求項１に記載のシステム。
【請求項１４】
前記システム・プロセッサは、
１）対象となる異常の種類の集合を決定し、
２）前記決定された対象となる異常の種類ごとに、
（ａ）前記システム・データ・ストアから受信された電子通信に関連する累積データに少なくとも部分的に基づいて、それぞれの異常の種類に関連する１つ以上の異常閾値を獲得し、
（ｂ）前記記憶されたリスク・プロファイル内の情報を前記獲得された１つ以上の異常閾値と比較し、
（ｃ）前記比較に基づいて前記受信された電子通信に関してそれぞれの異常の種類の異常が存在するか否かを判定する
ことによって、異常が存在するか否かを判定する請求項１に記載のシステム。
【請求項１５】
前記システム・プロセッサは前記システム・データ・ストアから構成情報を読み出すことによって前記対象となる異常の種類の集合を決定する請求項１４に記載のシステム。
【請求項１６】
前記システム・プロセッサは前記受信された電子通信に基づいて前記対象となる異常の種類の集合を決定する請求項１４に記載のシステム。
【請求項１７】
前記システム・プロセッサは前記受信された電子通信に関連する前記累積データから少なくとも１つの異常閾値を導出することによって１つ以上の異常閾値を獲得する請求項１４に記載のシステム。
【請求項１８】
前記少なくとも１つの異常閾値の導出はさらに所定の期間をベースに行われる請求項１７に記載のシステム。
【請求項１９】
前記システム・プロセッサは前記システム・データ・ストアから構成情報を読み出すことによって前記１つ以上の異常閾値のうち少なくとも１つの異常閾値を獲得する請求項１４に記載のシステム。
【請求項２０】
前記異常表示信号は管理者に伝達される通知を含む請求項１に記載のシステム。
【請求項２１】
前記通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む請求項２０に記載のシステム。
【請求項２２】
前記異常表示信号はさらに異常の種類を含むとともに、前記管理者に伝達される通知は異常の種類を含む請求項２０に記載のシステム。
【請求項２３】
前記異常表示信号は異常の種類を含む請求項１に記載のシステム。
【請求項２４】
前記システムはファイアウォール・システムと１つ以上のアプリケーション・サーバー・システムとの間に配置される請求項１に記載のシステム。
【請求項２５】
前記システムを前記ファイアウォール・システムと通信可能に結合するファイアウォール通信インターフェースをさらに備え、前記システム・プロセッサは前記選択されたアプリケーション・サーバー・システムに向けられた電子通信を、前記ファイアウォール通信インターフェースを介して受信する請求項２４に記載のシステム。
【請求項２６】
前記システム・プロセッサはさらに、前記受信された電子通信を、前記受信された電子通信によって指示された宛先へと送出する請求項１に記載のシステム。
【請求項２７】
前記システム・プロセッサはさらに前記記憶されたリスク・ファイルを前記受信された電子通信に関連する前記累積データと統合して、前記統合されたデータを前記システム・データ・ストア内に記憶する請求項１に記載のシステム。
【請求項２８】
前記システム・プロセッサはさらに前記受信された電子通信を前記システム・データ・ストアに記憶する請求項１に記載のシステム。
【請求項２９】
前記システム・プロセッサはさらに前記受信された通信に課せられるテストを決定する請求項１に記載のシステム。
【請求項３０】
前記システム・プロセッサは前記システム・データ・ストア内に記憶された構成情報に基づいて課せられるテストを決定する請求項２９に記載のシステム。
【請求項３１】
前記システム・プロセッサは前記受信された電子通信の特徴に基づいて課せられるテストを決定する請求項２９に記載のシステム。
【請求項３２】
前記システム・プロセッサはさらに、それを介して管理者が構成情報を入力し、インターフェースから構成情報を受信し、前記受信された構成情報を前記システム・データ・ストアに記憶するインターフェースを備える請求項１に記載のシステム。
【請求項３３】
前記システム・プロセッサは前記記憶された構成情報に基づいて前記１つ以上のテストを課す請求項３２に記載のシステム。
【請求項３４】
前記システム・プロセッサは前記記憶された構成情報に基づいて異常が存在するか否かを判定する請求項３２に記載のシステム。
【請求項３５】
前記記憶された構成情報は異常の種類、異常の閾値情報、異常の期間情報、または異常応答情報を含む請求項３４に記載のシステム。
【請求項３６】
前記システム・プロセッサはＷｅｂサーバー、ｅ−メール・サーバー、自動音声認識システムまたはＳＭＳメッセージ・サーバーを介して管理人にインターフェースを供給する請求項３２に記載のシステム。
【請求項３７】
前記システム・プロセッサはさらに、インターフェースを管理者に供給する前に前記インターフェースにデフォールト値を投入する請求項３２に記載のシステム。
【請求項３８】
前記システム・プロセッサはさらに前記異常表示信号に応答する修正手段を講じる請求項１に記載のシステム。
【請求項３９】
前記修正手段は通知を管理人に伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り（ｓｔｒｉｐｐｉｎｇ）、または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによって管理可能なレベルまで抑制することを含む請求項３８に記載のシステム。
【請求項４０】
前記通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む請求項３９に記載のシステム。
【請求項４１】
１つ以上のアプリケーション・サーバー・システムはｅ−メール・サーバー・システム、Ｗｅｂサーバー・システム、ＦＴＰサーバー・システム、テルネット・サーバー・システム、ＧＯＰＨＥＲサーバー・システム、またはＷＡＩＳサーバー・システムを含む請求項１に記載のシステム。
【請求項４２】
前記１つ以上のアプリケーション・サーバー・システムはｅ−メール・サーバー・システムである請求項４１に記載のシステム。
【請求項４３】
アプリケーション層通信セキュリティを強化する方法であって、
ａ）選択されたアプリケーション・サーバー・システムに向けられた、またはそこからの電子通信を受信し、受信された電子通信はアプリケーション層通信であり、
ｂ）前記受信された電子通信に１つ以上のテストを課し、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された電子通信を評価し、
ｃ）課せられる１つ以上のテストに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定し、
ｄ）異常の存在が判定されると異常表示信号を出力するステップを含む方法。
【請求項４４】
前記受信された電子通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む請求項４３に記載の方法。
【請求項４５】
前記受信された電子通信はｅ−メール通信である請求項４４に記載の方法。
【請求項４６】
前記１つ以上のテストを課すステップは、侵入検出テスト、ウイルス検出テスト、スパム検出テスト、または方針違反テストの１つ以上を課すことを含む請求項４３に記載の方法。
【請求項４７】
前記１つ以上のテストを課すステップは、複数のテストを順次に課すステップを含む請求項４３に記載の方法。
【請求項４８】
前記１つ以上のテストを課すステップは、前記複数の各テストごとに
ｉ）実施されるテストを選択し、
ｉｉ）前記受信された電子通信で前記選択されたテストを実施し、かつ
ｉｉｉ）前記実施されたテストに基づいてリスク・プロファイルを出力するステップを含む請求項４７に記載の方法。
【請求項４９】
構成情報を受信するステップをさらに備えると共に、テストを選択するステップは前記受信された構成情報に基づいてテストを選択することを含む請求項４８に記載の方法。
【請求項５０】
テストを選択するステップは前記受信された構成情報に基づいてテストを選択することを含む請求項４８に記載の方法。
【請求項５１】
構成情報を受信するステップをさらに備えると共に、異常が存在するか否かを判定するステップはさらに、前記受信された構成情報に基づいて行われる請求項４３に記載の方法。
【請求項５２】
前記受信された構成情報は異常の種類および異常応答情報を含む請求項５１に記載の方法。
【請求項５３】
前記受信された通信に関連する累積データを受信するステップをさらに含むと共に、前記異常が存在するか否かを判定するステップは、前記受信された累積データから異常閾値情報を導出することを含む請求項５２に記載の方法。
【請求項５４】
前記受信された構成情報はさらに異常閾値情報または異常期間情報を含む請求項５２に記載の方法。
【請求項５５】
前記受信された通信に関連する累積データを受信するステップをさらに含むと共に、前記異常が存在するか否かを判定するステップは前記受信された通信に関連する前記受信された累積データに基づいて行われる請求項４３に記載の方法。
【請求項５６】
前記異常表示信号に応答する修正手段を講じるステップをさらに含む請求項４３に記載の方法。
【請求項５７】
システム・プロセッサによって実行されると、前記システム・プロセッサがアプリケーション層セキュリティを提供するようにさせる命令を記憶するコンピュータ読み出し可能媒体であって、前記システム・プロセッサが、
ａ）選択されたアプリケーション・サーバー・システムに向けられた、またはそこからの電子通信を受信し、受信された電子通信はアプリケーション層通信であり、
ｂ）前記受信された電子通信に１つ以上のテストを課し、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された電子通信を評価し、それによって前記電子通信に関連する少なくとも１つのリスク・プロファイルを作成し、
ｃ）課せられる１つ以上のテストに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定し、かつ、
ｄ）異常の存在が判定されると異常表示信号を出力するステップを実行するようにさせる命令が記憶されている媒体。
【請求項５８】
前記システム・プロセッサが前記電子通信を受信するようにさせる前記命令は、前記システム・プロセッサがｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を受信するようにさせる命令を含む請求項５７に記載の媒体。
【請求項５９】
前記システム・プロセッサが前記電子通信を受信するようにさせる前記命令は、前記システム・プロセッサがｅ−メール通信を受信するようにさせる命令を含む請求項５７に記載の媒体。
【請求項６０】
前記システム・プロセッサが前記電子通信を受信するようにさせる前記命令は、前記システム・プロセッサが侵入検出テスト、ウイルス検出テスト、スパム検出テスト、または方針違反テストの１つ以上を課すようにさせる命令を含む請求項５７に記載の媒体。
【請求項６１】
前記システム・プロセッサが１つ以上のテストを課すようにさせる前記命令は、前記システム・プロセッサが複数のテストを課すようにさせる命令を含む請求項５７に記載の媒体。
【請求項６２】
前記システム・プロセッサが１つ以上のテストを課すようにさせる前記命令は、前記システム・プロセッサが、
ｉ）実施されるテストを選択し、
ｉｉ）前記受信された電子通信で前記選択されたテストを実施し、かつ
ｉｉｉ）前記実施されたテストに基づいてリスク・プロファイルを出力するようにさせる命令を含む請求項６１に記載の媒体。
【請求項６３】
前記システム・プロセッサが異常が存在するか否かを判定するようにさせる前記命令は、前記システム・プロセッサが、
ｉ）対象となる異常の種類の集合を決定し、
ｉｉ）前記決定された対象となる異常の種類ごとに、
１）それぞれの異常の種類に関連する１つ以上の異常閾値を獲得し、
２）前記少なくとも１つのリスク・プロファイル内の情報を前記獲得された１つ以上の異常閾値と比較し、かつ
３）前記比較に基づいて前記受信された電子通信に関してそれぞれの異常の種類の異常が存在するか否かを判定するようにさせる命令を含む請求項５７に記載の媒体。
【請求項６４】
前記システム・プロセッサが前記異常表示信号を出力するようにさせる前記命令は、前記システムが管理者に通知を伝達ようにさせる命令を含み、前記通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む請求項５７に記載の媒体。
【請求項６５】
アプリケーション層セキュリティ・システムであって、
ａ）アプリケーション層電子通信を受信するための受信手段と、
ｂ）電子通信と、受信された電子通信に関連する累積データとを記憶する記憶手段と、
ｃ）前記受信された電子通信を特定のセキュリティ・リスクについて各々が査定する１つ以上のテストを前記受信された電子通信に課し、かつ前記記憶手段にリスク・プロファイルを記憶するための査定手段であって、前記リスク・プロファイルは前記１つ以上のテストを前記受信された電子通信に課すことによって作成されたものである査定手段と、
ｄ）前記記憶手段内の前記リスク・プロファイルおよび前記受信された電子通信に関連する累積データに基づいて、前記受信された電子通信に関して異常が存在するか否かを判定するための異常判定手段と、
ｅ）前記異常判定手段によって異常が存在することが判定されると、異常表示信号を出力する出力手段とを備えるセキュリティ・システム。
【請求項６６】
通信ネットワークを経て送信される通信に質問するセキュリティ・システムであって、
ａ）前記システムを通信ネットワークに通信可能に結合する通信インターフェースと、
ｂ）システム・データ・ストアであって、
ｉ）通信を記憶可能なメッセージ・データ・ストアと、
ｉｉ）複数のインデックス待ち行列を記憶可能な待ち行列データ・ストアとを備えたシステム・データ・ストアと、
ｃ）前記通信インターフェースおよび前記システム・データ・ストアと通信し、１つ以上の処理要素を備えたシステム・プロセッサであって、
ｉ）前記通信インターフェースを介して通信を受信し、
ｉｉ）前記受信したメッセージを前記メッセージ・データ・ストア内に記憶し、
ｉｉｉ）選択されたインデックスを前記メッセージ・データ・ストアに割り当て、
ｉｖ）複数の質問エンジンを実行し、前記質問エンジンの各々はテストの種類を有し、かつこれに関連する待ち行列データ・ストア内にインデックス待ち行列を有しており、各質問エンジンは、
１）付されたインデックスごとに関連するインデックス待ち行列を監視し、
２）前記付されたインデックスに関連する通信を前記メッセージ・データ・ストアから検索し、
３）前記検索された通信を前記質問エンジンのテストの種類に関する１つ以上の判定基準の集合に対して査定し、
４）前記１つ以上の判定基準の集合に対する前記受信された通信の査定結果を表示する査定表示を出力し、
ｖ）前記システム・プロセッサは、前記選択されたインデックスを第一のテストの種類を有する第一質問エンジンに関連するインデックス待ち行列内に配し、
ｖｉ）前記第一質問エンジンによって出力される査定表示に応答して、前記選択されたインデックスを第一のテストの種類とは異なる第二のテストの種類を有する第二質問エンジンに関連するインデックス待ち行列内に配するシステム・プロセッサとを備えるシステム。
【請求項６７】
前記受信された電子通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む請求項６６に記載のシステム。
【請求項６８】
前記受信された電子通信はｅ−メール通信である請求項６７に記載のシステム。
【請求項６９】
前記システム・プロセッサは以前に割り当てられたインデックスを検索し、所定量だけ増分することによって前記選択されたインデックスを割り当てる請求項６６に記載のシステム。
【請求項７０】
前記システム・プロセッサは前記検索された通信に基づいて前記選択されたインデックスを割り当てる請求項６６に記載のシステム。
【請求項７１】
前記複数個の質問エンジンはさらに、前記選択されたインデックスに関連する通信を以前に査定したどの質問エンジンとも種類がそれぞれ異なる１つ以上のさらに別の質問エンジンを備えると共に、前記システム・プロセッサは質問エンジンによって出力される査定表示に応答して、前記選択されたインデックスに関連する通信を以前に査定したどの質問エンジンとも種類がそれぞれ異なる質問エンジンに関連するインデックス待ち行列内に前記選択されたインデックスを配する請求項６６に記載のシステム。
【請求項７２】
前記複数の質問エンジンは各々、侵入検出、ウイルス検出、スパム検出、または方針違反検出を含む請求項６６に記載のシステム。
【請求項７３】
前記システム・プロセッサは前記受信された通信に基づいて前記複数の質問エンジンに質問エンジンを追加する請求項６６に記載のシステム。
【請求項７４】
前記システム・プロセッサは、前記複数の質問エンジン内の既存の質問エンジンのローディングに基づいて前記複数の質問エンジンに質問エンジンを追加する請求項６６に記載のシステム。
【請求項７５】
各質問エンジンによって出力される前記査定表示は、前記質問エンジンのテストの種類に関して受信された通信に関連するリスク・レベルを含んでいる請求項６６に記載のシステム。
【請求項７６】
各質問エンジンによって出力される前記査定表示は、前記１つ以上の判定基準の集合に関する前記質問エンジンによる前記受信された通信の査定が、前記受信された通信が閾値リスク・レベルに適合すると判定された場合だけ出力される請求項６６に記載のシステム。
【請求項７７】
前記査定表示信号は管理者に伝達される通知を含む請求項７６に記載のシステム。
【請求項７８】
前記通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む請求項７７に記載のシステム。
【請求項７９】
前記査定表示はさらに前記査定表示を出力する前記質問エンジンのテストの種類を含むと共に、前記管理者に伝達される前記通知は前記質問エンジンのテストの種類を含む請求項７７に記載のシステム。
【請求項８０】
前記システム・プロセッサは、前記複数の質問エンジン内の既存のエンジンのローディングに基づいて前記複数の質問エンジンから質問エンジンを削除する請求項６６に記載のシステム。
【請求項８１】
前記システム・データ・ストアはさらに、構成情報を記憶可能な構成データ・ストアを備える請求項６６に記載のシステム。
【請求項８２】
前記システム・プロセッサはさらに、受信された通信から累積されたデータに基づいて構成情報を更新する請求項８１に記載のシステム。
【請求項８３】
前記システム・プロセッサはさらに、管理者がそれを介して構成情報を入力し、インターフェースから構成情報を受信し、受信した構成情報を前記システム・データ・ストアに記憶させるインターフェースを備える請求項８１に記載のシステム。
【請求項８４】
前記システム・プロセッサはさらに、インターフェースを管理者に供給する前にこれに１つ以上のデフォールト値を投入する請求項８３に記載のシステム。
【請求項８５】
前記システム・プロセッサはＷｅｂサーバー、ｅ−メール・サーバー、自動音声認識システム、またはＳＭＳメッセージ・サーバーを介してインターフェースを供給する請求項８３に記載のシステム。
【請求項８６】
前記システム・プロセッサはさらに、構成データ・ストアに記憶されている構成情報に基づいて第一質問エンジンを決定する請求項８１に記載のシステム。
【請求項８７】
前記システム・プロセッサはさらに、構成データ・ストアに記憶されている構成情報に基づいて第二質問エンジンを決定する請求項８１に記載のシステム。
【請求項８８】
前記システム・プロセッサはさらに、構成データ・ストアに記憶されている構成情報に基づいて複数の質問エンジンを決定する請求項８１に記載のシステム。
【請求項８９】
前記システムをファイアウォール・システムに通信可能に結合するファイアウォール通信インターフェースをさらに備え、前記システム・プロセッサは前記ファイアウォール通信インターフェースを介して前記通信を受信する請求項６６に記載のシステム。
【請求項９０】
前記システムをファイアウォール・システムに通信可能に結合するファイアウォール通信インターフェースをさらに備え、前記受信された通信は前記通信ネットワーク外の宛先アドレスで前記通信ネットワークに接続されたシステムから発信されている請求項６６に記載のシステム。
【請求項９１】
前記受信された通信は前記通信ネットワークに接続されたシステムに向けられる請求項６６に記載のシステム。
【請求項９２】
前記受信された通信は前記通信ネットワークに接続されたシステムから発信されている請求項６６に記載のシステム。
【請求項９３】
前記システム・プロセッサはさらに前記受信された通信を宛先へと送出する請求項６６に記載のシステム。
【請求項９４】
前記システム・プロセッサはさらに前記通信に基づいて前記通信の宛先を判定する請求項９３に記載のシステム。
【請求項９５】
前記システム・プロセッサはさらに複数の質問エンジンからそれぞれ出力された１つ以上の査定表示に応答して全体的な表示信号を出力する請求項６６に記載のシステム。
【請求項９６】
前記システム・プロセッサはさらに複数の質問エンジンからそれぞれ出力された１つ以上の査定表示に応答して修正手段を講じる請求項６６に記載のシステム。
【請求項９７】
前記修正手段は通知を管理人に伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を、通信ネットワークにとって管理可能なレベルまで抑制することを含む請求項９６に記載のシステム。
【請求項９８】
通信ネットワークを経て送信される通信に質問する方法であって、
ａ）通信ネットワークを介して送信された通信を受信し、
ｂ）前記受信した通信に選択されたインデックスを割り当て、
ｃ）複数の質問エンジンを実行し、前記質問エンジンの各々はテストの種類を有し、かつこれに関連するインデックス待ち行列を有しており、各質問エンジンは、
ｉ）付されたインデックスごとに関連するインデックス待ち行列を監視し、
ｉｉ）前記付されたインデックスに関連する通信を前記質問エンジンに関する１つ以上の判定基準に対して査定し、かつ、
ｉｉｉ）前記１つ以上の判定基準の集合に対して付されたインデックスに関連する通信の査定結果を表示する査定表示を出力する工程を実行し、
ｄ）前記選択されたインデックスを第一のテストの種類を有する第一質問エンジンに関連するインデックス待ち行列内に配し、
ｅ）前記第一質問エンジンによって出力される査定表示に応答して、前記選択されたインデックスを第一のテストの種類とは異なる第二のテストの種類を有する第二質問エンジンに関連するインデックス待ち行列内に配する工程を含む方法。
【請求項９９】
前記受信された電子通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む請求項９８に記載の方法。
【請求項１００】
前記受信された電子通信はｅ−メール通信である請求項９９に記載の方法。
【請求項１０１】
前記複数個の質問エンジンは、前記選択されたインデックスに関連する通信を以前に査定したどの質問エンジンとも種類がそれぞれ異なる１つ以上のさらに別の質問エンジンを備えると共に、前記通信を以前に査定した質問エンジンによって出力される査定表示に応答して、前記選択されたインデックスに関連する通信を以前に査定したどの質問エンジンとも種類がそれぞれ異なる後続の質問エンジンに関連するインデックス待ち行列内に前記選択されたインデックスを配する工程を含む請求項９８に記載の方法。
【請求項１０２】
前記複数の質問エンジンは各々、侵入検出、ウイルス検出、スパム検出、または方針違反検出を含む請求項９８に記載の方法。
【請求項１０３】
前記受信された通信に基づいて前記複数の質問エンジンに質問エンジンを追加する工程をさらに含む請求項９８に記載の方法。
【請求項１０４】
前記複数の質問エンジン内の既存の質問エンジンのローディングに基づいて前記複数の質問エンジンに質問エンジンを追加する工程をさらに含む請求項９８に記載の方法。
【請求項１０５】
各質問エンジンによって出力される前記査定表示は、前記１つ以上の判定基準の集合に関する前記質問エンジンによる前記受信された通信の査定で、前記受信された通信が閾値リスク・レベルに適合すると判定された場合だけ出力される請求項９８に記載の方法。
【請求項１０６】
前記査定表示信号は管理者に伝達される通知を含む請求項１０５に記載の方法。
【請求項１０７】
前記複数の質問エンジン内の既存のエンジンのローディングに基づいて前記複数の質問エンジンから質問エンジンを削除する工程を含む請求項９８に記載の方法。
【請求項１０８】
複数の質問エンジンからそれぞれ出力された１つ以上の査定表示に応答して修正手段を講じる工程を含む請求項９８に記載の方法。
【請求項１０９】
前記修正手段は通知を管理人に伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を、通信ネットワークにとって管理可能なレベルまで抑制する工程を含む請求項１０８に記載のシステム。
【請求項１１０】
システム・プロセッサによって実行されると、システム・プロセッサが通信ネットワークを介して送信される通信に質問するようにさせる命令を記憶するコンピュータ読み出し可能媒体であって、前記システム・プロセッサが下記の工程、すなわち、
ａ）通信ネットワークを介して送信された通信を受信し、
ｂ）前記受信した通信に選択されたインデックスを割り当て、
ｃ）複数の質問エンジンを実行し、前記質問エンジンの各々はテストの種類を有し、かつこれに関連するインデックス待ち行列を有しており、各質問エンジンは、
ｉ）付されたインデックスごとに関連するインデックス待ち行列を監視し、
ｉｉ）前記付されたインデックスに関連する通信を前記質問エンジンの種類に関する１つ以上の判定基準に対して査定し、かつ、
ｉｉｉ）前記１つ以上の判定基準の集合に対して付されたインデックスに関連する通信の査定結果を表示する査定表示を出力する工程を実行し、かつ、
ｄ）前記選択されたインデックスを第一のテストの種類を有する第一質問エンジンに関連するインデックス待ち行列内に配し、
ｅ）前記第一質問エンジンによって出力される査定表示に応答して、前記選択されたインデックスを第一のテストの種類とは異なる第二のテストの種類を有する第二質問エンジンに関連するインデックス待ち行列内に配する工程を実行するようにさせる命令を記憶しているコンピュータ読み出し可能媒体。
【請求項１１１】
前記システム・プロセッサが前記電子通信を受信するようにさせる前記命令は、前記システム・プロセッサがｅ−メール通信を受信するようにさせる命令を含む請求項１１０に記載の媒体。
【請求項１１２】
前記複数個の質問エンジンはさらに、前記選択されたインデックスに関連する通信を以前に査定したどの質問エンジンとも種類がそれぞれ異なる１つ以上のさらに別の質問エンジンを備えると共に、以前に査定した質問エンジンによって出力される査定表示に応答して、前記選択されたインデックスに関連する通信を以前に査定したどの質問エンジンとも種類がそれぞれ異なる後続の質問エンジンに関連するインデックス待ち行列内に前記選択されたインデックスを配する工程を前記システム・プロセッサが実行するようにさせる命令をさらに備える請求項１１０に記載の媒体。
【請求項１１３】
前記複数の質問エンジンは各々、侵入検出、ウイルス検出、スパム検出、または方針違反検出を含む請求項１１０に記載の媒体。
【請求項１１４】
前記システム・プロセッサが、前記複数の質問エンジン内の既存の質問エンジンのローディングに基づいて前記複数の質問エンジンに質問エンジンを追加する工程を実行するようにさせる命令をさらに含む請求項１１０に記載の媒体。
【請求項１１５】
各質問エンジンによって出力される前記査定表示は、前記１つ以上の判定基準の集合に関する前記質問エンジンによる前記受信された通信の査定で、前記受信された通信は閾値リスク・レベルに適合すると判定された場合だけ出力される請求項１１０に記載の媒体。
【請求項１１６】
前記システム・プロセッサが、前記複数の質問エンジン内の既存のエンジンのローディングに基づいて前記複数の質問エンジンから質問エンジンを削除する工程を実行するようにさせる命令をさらに含む請求項１１０に記載の媒体。
【請求項１１７】
前記システム・プロセッサが、前記複数の質問エンジンからそれぞれ出力された１つ以上の査定表示に応答して修正手段を講じる工程を実行するようにさせる命令をさらに含む請求項１１０に記載の媒体。
【請求項１１８】
通信ネットワークを経て送信された通信に質問するセキュリティ・システムであって、
ａ）通信ネットワークを介して送信された通信を受信する受信手段と、
ｂ）受信した通信と複数のインデックス待ち行列とを記憶する記憶手段と、
ｃ）前記選択されたインデックスを記憶された通信に割り当てる割り当て手段と、
ｄ）複数の質問エンジンを実行し、前記質問エンジンの各々はテストの種類を有し、かつこれに関連するインデックス待ち行列を有している質問エンジン管理手段であって、各質問エンジンは、
１）付されたインデックスごとに関連するインデックス待ち行列を監視し、
２）付されたインデックスに関連する通信を前記メッセージ・データ・ストアから検索し、
３）前記検索された通信を前記質問エンジンのテストの種類に関する１つ以上の判定基準に対して査定し、かつ、
４）前記１つ以上の判定基準の集合に関する前記検索された通信の査定結果を表示する査定表示を出力する工程を実行する質問エンジン管理手段と、
ｅ）前記選択されたインデックスを質問エンジンに関連するインデックス待ち行列に配するインデックス付与手段とを備え、前記インデックス付与手段は、前記インデックス割り当て手段による前記選択されたインデックスの割り当てに応答して、前記選択されたインデックスを第一質問エンジンのインデックス待ち行列に配すると共に、前記インデックス付与手段は、前記通信を以前に査定した質問エンジンによって出力される査定表示に応答して、前記選択されたインデックスに関連する通信を以前に査定したどの質問エンジンとも種類がそれぞれ異なる後続の質問エンジンに関連するインデックス待ち行列内に前記選択されたインデックスを配するセキュリティ・システム。
【請求項１１９】
通信ネットワークを経て送信される異常通信を検出するシステムであって、
ａ）前記システムを前記通信ネットワークに結合するインターフェースと、
ｂ）前記通信ネットワークを経て送信された通信に関連するデータ、および異常が検出されると開始される１つ以上の応答に関連する情報を記憶できるシステム・データ・ストアと、
ｃ）前記インターフェースおよび前記データ・ストアと通信するシステム・プロセッサとを備え、前記システム・プロセッサは１つ以上の処理要素を含み、前記システム・プロセッサは、
ｉ）収集エンジンであって、
１）前記インターフェースを経て通信を受信し、
２）１つ以上のテストを前記受信された通信に課すことによって前記受信された通信に関連するデータを生成する収集エンジンと、
ｉｉ）前記収集エンジンによって生成されたデータと、前記システム・データ・ストアからの以前受信した通信に関連するデータとに基づいて前記受信された通信に対して異常が存在するか否かを検出する分析エンジンと、
ｉｉｉ）前記分析エンジンによって異常が検出されると前記システム・データ・ストアからの所定の応答を開始するアクション・エンジンとを実施するシステム。
【請求項１２０】
前記受信された電子通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む請求項１１９に記載のシステム。
【請求項１２１】
前記受信された電子通信はｅ−メール通信である請求項１２０に記載のシステム。
【請求項１２２】
前記収集エンジンによって課せられる１つ以上のテストは各々、侵入検出、ウイルス検出、スパム検出、または方針違反検出を含む請求項１１９に記載のシステム。
【請求項１２３】
前記収集エンジンは複数のテストを課す請求項１１９に記載のシステム。
【請求項１２４】
前記収集エンジンは前記複数のテストの各々を並行して課す請求項１２３に記載のシステム。
【請求項１２５】
前記収集エンジンは前記複数のテストの各々を順次に課す請求項１２３に記載のシステム。
【請求項１２６】
前記システム・データ・ストアは構成情報を記憶すると共に、前記収集エンジンは前記システム・データ・ストアに記憶されている構成情報に基づいて前記１つ以上のテストの各々を課す請求項１１９に記載のシステム。
【請求項１２７】
前記分析エンジンは前記システム・データ・ストアに記憶されている構成情報に基づいて異常が存在するか否かを判定する請求項１１９に記載のシステム。
【請求項１２８】
前記構成情報は異常の種類、異常の閾値情報、異常の期間情報、または異常応答情報を含む請求項１２７に記載のシステム。
【請求項１２９】
前記分析エンジンはさらに受信された電子通信に関連する前記システム・データ・ストア内の前記累積データから１つ以上の異常閾値を導出すると共に、前記分析エンジンはさらに導出された１つ以上の異常閾値に基づいて異常が存在するか否かを検出する請求項１１９に記載のシステム。
【請求項１３０】
前記分析エンジンは、
１）対象となる異常の種類の集合を決定し、
２）前記決定された対象となる異常の種類ごとに、
（ａ）前記システム・データ・ストアから受信された電子通信に関連する累積データに少なくとも部分的に基づいて、それぞれの異常の種類に関連する１つ以上の異常閾値を獲得し、
（ｂ）前記記憶されたリスク・プロファイル内の情報を前記獲得された１つ以上の異常閾値と比較し、
（ｃ）前記比較に基づいて前記受信された電子通信に関してそれぞれの異常の種類の異常が存在するか否かを判定する
ことによって、異常が存在するか否かを判定する請求項１１９に記載のシステム。
【請求項１３１】
前記システム・データ・ストアは構成情報を記憶すると共に、前記分析エンジンは前記システム・データ・ストアから構成情報を読み出すことによって前記対象となる異常の種類の集合を決定する請求項１３０に記載のシステム。
【請求項１３２】
前記分析エンジンは前記受信された電子通信に基づいて前記対象となる異常の種類の集合を決定する請求項１３０に記載のシステム。
【請求項１３３】
前記分析エンジンは前記受信された通信に関連する前記累積データから少なくとも１つの異常閾値を導出することによって１つ以上の異常閾値を獲得する請求項１３０に記載のシステム。
【請求項１３４】
前記少なくとも１つの異常閾値の導出はさらに所定の期間をベースに行われる請求項１３３に記載のシステム。
【請求項１３５】
前記システム・データ・ストアは構成情報を記憶すると共に、前記分析エンジンは前記システム・データ・ストアから構成情報を読み出すことによって前記１つ以上の異常閾値のうち少なくとも１つの異常閾値を獲得する請求項１３０に記載のシステム。
【請求項１３６】
前記アクション・エンジンの開始される所定の応答は前記分析エンジンによって検出された異常に関連する異常の種類に基づく応答である請求項１１９に記載のシステム。
【請求項１３７】
前記アクション・エンジンの開始される所定の応答は、通知を管理人に伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を管理可能なレベルまで抑制することを含む請求項１１９に記載のシステム。
【請求項１３８】
前記アクション・エンジンの開始される所定の応答は管理者に通知を伝達することを含み、前記通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む請求項１３７に記載のシステム。
【請求項１３９】
前記システム・プロセッサはさらに、前記収集エンジンにとって生成されたデータを以前受信された通信と統合し、統合されたデータを前記システム・データ・ストアに記憶する請求項１１９に記載のシステム。
【請求項１４０】
前記システム・プロセッサはさらに、それを介して管理者が構成情報を入力し、インターフェースから構成情報を受信し、前記受信された構成情報を前記システム・データ・ストアに記憶するインターフェースを備える請求項１１９に記載のシステム。
【請求項１４１】
前記収集エンジンは前記記憶された構成情報に基づいて前記１つ以上のテストを課す請求項１４０に記載のシステム。
【請求項１４２】
前記分析エンジンは前記記憶された構成情報に基づいて異常が存在するか否かを検出する請求項１４０に記載のシステム。
【請求項１４３】
前記記憶された構成情報は異常の種類、異常の閾値情報、異常の期間情報、または異常応答情報を含む請求項１４２に記載のシステム。
【請求項１４４】
前記システム・プロセッサはＷｅｂサーバー、ｅ−メール・サーバー、自動音声認識システムまたはＳＭＳメッセージ・サーバーを介して管理人にインターフェースを供給する請求項１４０に記載のシステム。
【請求項１４５】
前記システム・プロセッサはさらに、インターフェースを管理者に供給する前に前記インターフェースにデフォールト値を投入する請求項１４０に記載のシステム。
【請求項１４６】
通信ネットワークを経て送信された異常通信を検出する方法であって、
ａ）通信ネットワークを経て通信を受信し、
ｂ）１つ以上のテストを前記受信された通信に課すことによって前記受信された通信に関連するデータを生成し、
ｃ）１つ以上の以前受信された通信に関連するデータを獲得し、
ｄ）前記生成されたデータと獲得されたデータとに基づいて前記受信された通信に対して異常が存在するか否かを検出し、
ｅ）異常が検出されると所定の応答を開始する
工程を含む方法。
【請求項１４７】
前記受信された電子通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信である請求項１４６に記載の方法。
【請求項１４８】
前記受信された電子通信はｅ−メール通信である請求項１４７に記載の方法。
【請求項１４９】
前記収集エンジンによって課せられる１つ以上のテストは各々、侵入検出、ウイルス検出、スパム検出、または方針違反検出を含む請求項１４６に記載の方法。
【請求項１５０】
前記１つ以上のテストを課す工程は複数のテストを課す工程である請求項１４６に記載の方法。
【請求項１５１】
前記獲得されたデータから１つ以上の異常閾値を導出する工程をさらに含むと共に、異常が存在するか否かを検出する前記工程はさらに、前記導出された１つ以上の異常閾値を超える異常が存在するか否かの検出をベースにする請求項１４６に記載の方法。
【請求項１５２】
異常が存在するか否かを検出する前記工程は
ａ）対象となる異常の種類の集合を決定し、
ｂ）前記決定された対象となる異常の種類ごとに、
ｉ）以前受信された１つ以上の通信に関連するか獲得されたデータに少なくとも部分的に基づいて、それぞれの異常の種類に関連する１つ以上の異常閾値を獲得し、
ｉｉ）前記記憶されたリスク・プロファイル内の情報を前記獲得された１つ以上の異常閾値と比較し、
ｉｉｉ）前記比較に基づいて前記受信された通信に関してそれぞれの異常の種類の異常が存在するか否かを判定する工程を含む請求項１４６に記載の方法。
【請求項１５３】
前記対象となる異常の種類の集合の決定は、構成情報を読み出す工程を含む請求項１５２に記載の方法。
【請求項１５４】
前記対象となる異常の種類の集合の決定は、前記受信された電子通信に基づいて前記集合を決定する請求項１５２に記載の方法。
【請求項１５５】
１つ以上の異常閾値を獲得する前記工程は、前記１つ以上の以前受信された通信に関連する前記獲得されたデータから少なくとも１つの異常閾値を導出する工程を含む請求項１５２に記載の方法。
【請求項１５６】
前記開始される所定の応答は前記検出された異常に関連する異常の種類に基づく応答である請求項１４６に記載の方法。
【請求項１５７】
前記開始される所定の応答は、通知を管理人に伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を管理可能なレベルまで抑制することを含む請求項１４６に記載の方法。
【請求項１５８】
前記開始される所定の応答は管理者に通知を伝達することを含み、前記通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む請求項１５７に記載の方法。
【請求項１５９】
システム・プロセッサによって実行されると、システム・プロセッサが通信ネットワークを介して送信される通信に質問するようにさせる命令を記憶するコンピュータ読み出し可能媒体であって、前記システム・プロセッサが下記の工程、すなわち、
ａ）通信ネットワークを介して送信された通信を受信し、
ｂ）１つ以上のテストを前記受信された通信に課すことによって前記受信された通信に関連するデータを生成し、
ｃ）１つ以上の以前受信された通信に関連するデータを獲得し、
ｄ）前記生成されたデータと獲得されたデータとに基づいて前記受信された通信に対して異常が存在するか否かを検出し、
ｅ）異常が検出されると所定の応答を開始する
工程を実行するようにさせる記憶された命令を含む媒体。
【請求項１６０】
前記システム・プロセッサが前記電子通信を受信するようにさせる前記命令は、前記システム・プロセッサがｅ−メール通信を受信するようにさせる命令を含む請求項１５９に記載の媒体。
【請求項１６１】
前記システム・プロセッサが１つ以上のテストを課すようにさせる前記命令は、前記システム・プロセッサが侵入検出テスト、ウイルス検出テスト、スパム検出テスト、または方針違反テストの１つ以上を課すようにさせる命令を含む請求項１５９に記載の媒体。
【請求項１６２】
前記システム・プロセッサが異常が存在するか否かを検出するようなさせる前記命令は、前記システム・プロセッサが、
ａ）対象となる異常の種類の集合を決定し、
ｂ）前記決定された対象となる異常の種類ごとに、
ｉ）前記以前受信された１つ以上の通信に関連する獲得されたデータに少なくとも部分的に基づいて、それぞれの異常の種類に関連する１つ以上の異常閾値を獲得し、
ｉｉ）前記記憶されたリスク・プロファイル内の情報を前記獲得された１つ以上の異常閾値と比較し、
ｉｉｉ）前記比較に基づいて前記受信された通信に関してそれぞれの異常の種類の異常が存在するか否かを判定する工程を実行するようにさせる命令を含む請求項１５９に記載の媒体。
【請求項１６３】
前記開始される所定の応答は検出された異常に関連する異常の種類に基づく応答である請求項１５９に記載の媒体。
【請求項１６４】
前記開始される所定の応答は、通知を管理人に伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を管理可能なレベルまで抑制することを含む請求項１５９に記載の媒体。
【請求項１６５】
通信ネットワークを経て送信される異常通信を検出するシステムであって、
ａ）前記通信ネットワークを経て送信された通信に関連するデータ、および異常が検出されると開始される１つ以上の応答に関連する情報を記憶をする記憶手段と、
ｂ）通信ネットワークを経て送信される通信を受信し、１つ以上のテストを前記受信された通信に課すことによって前記受信された通信に関連するデータを生成する収集手段と、
ｃ）前記収集手段によって生成されたデータと、前記記憶手段からの以前受信した通信に関連するデータとに基づいて前記受信された通信に対して異常が存在するか否かを検出する分析手段と、
ｄ）前記分析手段によって異常が検出されると前記記憶手段からの所定の応答を開始するアクション手段とを備えるシステム。
【請求項１６６】
脅威検出ルールを作成し、アプリケーション層セキュリティ・システムへと配信するための管理システムであって、
ａ）前記管理システムと少なくとも１つのアプリケーション層セキュリティ・システムとの通信を可能にするようにされた通信インターフェースと、
ｂ）１つ以上のデータ記憶素子を備え、
ｉ）１組以上の脅威管理目標の集合と、
ｉｉ）脅威情報と
を記憶可能であるシステム・データ・ストアと、
ｃ）前記通信インターフェースおよび前記システム・データ・ストアと通信されたシステム・プロセッサとを備え、前記システム・プロセッサは１つ以上の処理要素を備え、前記１つ以上の処理要素は、
ｉ）１つ以上のソースから脅威情報を受信し、
ｉｉ）前記受信した脅威情報を正規の形式に還元し、
ｉｉｉ）前記還元された情報から特徴を抽出し、
ｉｖ）前記抽出された特徴、および前記システム・データ・ストア内の１組以上の脅威管理目標の集合に基づいて１組以上の脅威ルールの集合を作成し、
ｖ）前記作成されたルールの集合を前記複数のアプリケーション層セキュリティ・システムの少なくとも１つに送信する
ようにプログラムされ、または適応化されている管理システム。
【請求項１６７】
前記システム・データ・ストアはさらに、１組以上のテスト・データの集合を記憶することができ、前記システム・プロセッサはさらに、前記作成されたルールの集合を前記システム・データ・ストア内の１組以上のテスト・データの集合に対して評価し、前記ルールの集合の評価が所定の信頼度レベルに満たない場合には前記ルール集合を改良するようにプログラムされ、または適応化されている請求項１６６に記載のシステム。
【請求項１６８】
前記システム・プロセッサは前記作成されたルール集合を、ルール集合を作成するために利用された目標の集合に基づく１組以上のテスト・データ集合に対して評価する請求項１６７に記載のシステム。
【請求項１６９】
第二の目標集合は有効性の値、精度値、効率値および誤検出の値の群から選択された１つ以上の値を備えている請求項１６８に記載のシステム。
【請求項１７０】
前記システム・プロセッサは前記作成されたルールの集合を、前記ルール集合を作成するために利用された目標の集合とは異なる前記システム・データ・ストアからの１組以上目標の集合のうちの第二の目標の集合に基づいて、１組以上のテスト・データの集合に対して評価する請求項１６７に記載のシステム。
【請求項１７１】
前記第二の目標集合は有効性の値、精度値、効率値および誤検出の値の群から選択された１つ以上の値を備えている請求項１７０に記載のシステム。
【請求項１７２】
前記目標の集合は有効性の値、精度値、効率値および誤検出の値からなる群から選択された１つ以上の属性を備えている請求項１６６に記載のシステム。
【請求項１７３】
前記目標の集合は１つ以上の不都合なメッセージの種類を含み、不都合な各メッセージの種類は、ビジネスｅ−メール、個人ｅ−メール、チェーン・メール、アダルト言語、ポルノ、ウエブ製品の提供、ニューズレター、メーリング・リスト、トロイ、ウォームおよびウイルスからなる群から選択される請求項１６６に記載のシステム。
【請求項１７４】
不都合な各メッセージの種類はメッセージの種類の不都合さのレベルに対応する値に関連付けられる請求項１７３に記載のシステム。
【請求項１７５】
前記システム・プロセッサはさらに前記システム・データ・ストアから前記目標の集合を選択するようにプログラムされ、または適応化されている請求項１６６に記載のシステム。
【請求項１７６】
前駆目標の集合を選択する前記システム・プロセッサのプログラムミングまたは適応化は、前記複数のアプリケーション層セキュリティ・システムから選択されたアプリケーション層セキュリティ・システムに少なくとも部分的に基づいて前記目標の集合を選択するプログラムミングまたは適応化を含む請求項１７５に記載のシステム。
【請求項１７７】
前記システム・プロセッサは前記作成されたルールの集合を前記少なくとも選択されたアプリケーション層セキュリティ・システムに送信する請求項１７６に記載のシステム。
【請求項１７８】
前記システム・プロセッサは選択されたアプリケーション層セキュリティ・システムからの脅威情報を、前記通信インターフェースを介して受信する請求項１６６に記載のシステム。
【請求項１７９】
前記システム・プロセッサは脅威情報をスパム・データベース、ウイルス・データベース、侵入情報データベース、およびこれらの組み合わせから受信する請求項１６６に記載のシステム。
【請求項１８０】
前記システム・プロセッサはさらに別の脅威情報を選択されたアプリケーション層セキュリティ・システムから通信インターフェースを介して受信する請求項１７９に記載のシステム。
【請求項１８１】
前記システム・プロセッサは前記複数のアプリケーション層セキュリティ・システムのうち少なくとも１つで利用できる種類の質問に各々が対応する特徴を抽出する請求項１６６に記載のシステム。
【請求項１８２】
前記システム・プロセッサは１つ以上の通常表現フィルタを利用して特徴を抽出する請求項１６６に記載のシステム。
【請求項１８３】
前記システム・プロセッサはさらに、少なくとも１つのルールおよび方針アプリケーション・プログラミング・インターフェースを受信するようにプログラムされ、または適応化されている請求項１６６に記載のシステム。
【請求項１８４】
前記システム・プロセッサは前記少なくとも１つのルールおよび方針アプリケーション・プログラミング・インターフェースに基づいて前記ルールの集合を作成する請求項１８３に記載のシステム。
【請求項１８５】
脅威情報を管理する方法であって、
ａ）脅威情報をアプリケーション層セキュリティ・システム、スパム・データベース、ウイルス・データベース、侵入情報データベースからなる群から選択された１つ以上のソースから受信する工程と、
ｂ）前記受信した情報を正規の形式に還元する工程と、
ｃ）１つ以上の通常の表現を適用することによって前記還元された脅威情報から特徴を抽出する工程と、
ｄ）前記複数のアプリケーション層セキュリティ・システムから選択されたアプリケーション層セキュリティ・システムに少なくとも部分的に基づいて、有効性の値、精度値、効率値および誤検出の値の群から選択された１つ以上の種類の値を含む１つ以上の脅威管理目標の目標集合を選択する工程と、
ｅ）前記抽出された特徴および目標集合に基づいて１つ以上の脅威ルールの候補ルールの集合を作成する工程と、
ｆ）前記候補のルール集合を１つ以上のテスト・データ集合に対してテストする工程と、
ｇ）前記ルール集合の前記評価が所定の信頼度レベルを満たさない場合は前記候補のルール集合を改良する工程と、
ｈ）前記候補の、または改良されたルール集合を少なくとも１つのアプリケーション層セキュリティ・システムに送信する工程と
を含む方法。
【請求項１８６】
脅威検出ルールを作成し、アプリケーション層セキュリティ・システムへと配信するための管理システムであって、
ａ）脅威情報をアプリケーション層セキュリティ・システム、スパム・データベース、ウイルス・データベース、侵入情報データベースからなる群から選択された１つ以上のソースから受信し、かつ作成されたルールの集合を少なくとも１つのアプリケーション層セキュリティ・システムに送信する通信手段と、
ｂ）ルール作成手段であって、
ｉ）前記受信した情報を正規の形式に還元し、
ｉｉ）１つ以上の通常の表現を適用することによって前記還元された脅威情報から特徴を抽出し、
ｉｉｉ）前記複数のアプリケーション層セキュリティ・システムから選択されたアプリケーション層セキュリティ・システムに少なくとも部分的に基づいて、有効性の値、精度値、効率値および誤検出の値の群から選択された１つ以上の種類の値を含む１つ以上の脅威管理目標の目標集合を選択し、
ｉｖ）前記抽出された特徴および目標集合に基づいて１つ以上の脅威ルールの候補ルールの集合を作成し、
ｖ）前記候補のルール集合を１つ以上のテスト・データ集合に対してテストし、
ｖｉ）前記ルール集合の前記評価が所定の信頼度レベルを満たさない場合は前記候補のルール集合を改良し、
ｖｉｉ）前記候補の、または改良されたルール集合を前記通信手段に送信するルール作成手段と
を含むシステム。
【請求項１８７】
アプリケーション層セキュリティ・システムであって、
ａ）前記セキュリティ・システムを、１つ以上の他のアプリケーション層セキュリティ・システムおよび脅威管理システムと通信可能にする通信ネットワークに通信可能に結合する少なくとも１つのアプリケーション・サーバー・システムと、
ｂ）電子通信および受信された電子通信に関連する累積データを記憶可能であるシステム・データ・ストアと、
ｃ）前記システム・データ・ストアおよび前記少なくとも１つのアプリケーション・サーバー・システム通信インターフェースと通信するシステム・プロセッサとを備え、前記システム・プロセッサは１つ以上の処理要素を備えると共に、前記システム・プロセッサは、
ｉ）選択されたアプリケーション・サーバー・システムに向けられた、またはそこからの電子通信を受信し、
ｉｉ）前記受信された電子通信に１つ以上のテストを課し、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された電子通信を評価し、
ｉｉｉ）課せられる１つ以上のテストに基づいて、前記受信された電子通信に関連するリスク・プロファイルをシステム・データ・ストアに記憶し、
ｉｖ）前記記憶されたリスク・プロファイルに基づいて、情報を第二アプリケーション層セキュリティ・システム、脅威管理センター、脅威プッシュバック・システムまたはこれらの組み合わせに出力するシステム。
【請求項１８８】
前記受信された電子通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む請求項１８７に記載のシステム。
【請求項１８９】
前記受信された電子通信はｅ−メール通信である請求項１８８に記載のシステム。
【請求項１９０】
前記システム・プロセッサによって課せられる１つ以上のテストは各々、侵入検出、ウイルス検出、スパム検出、または方針違反検出を含む請求項１８７に記載のシステム。
【請求項１９１】
前記システム・プロセッサは複数のテストを課す請求項１８７に記載のシステム。
【請求項１９２】
前記システム・プロセッサは前記複数のテストの各々を並行して課す請求項１９１に記載のシステム。
【請求項１９３】
前記システム・プロセッサは前記複数のテストの各々を順次に課す請求項１９１に記載のシステム。
【請求項１９４】
前記システム・プロセッサは前記システム・データ・ストアに記憶された構成情報に基づいて前記１つ以上のテストの各々を課す請求項１８７に記載のシステム。
【請求項１９５】
前記システム・プロセッサは情報をｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報の形式で出力する請求項１８７に記載のシステム。
【請求項１９６】
前記システム・プロセッサは情報を脅威管理センター、および第二アプリケーション層セキュリティ・システム、脅威プッシュバック・システムまたはこれらの組み合わせに出力する請求項１８７に記載のシステム。
【請求項１９７】
前記システム・プロセッサによって課せられる前記１つ以上のテストは異常検出を含む請求項１８７に記載のシステム。
【請求項１９８】
前記アプリケーション層セキュリティ・システムは少なくとも１つの他のアプリケーション層セキュリティ・システムにメッセージをブロードキャストすることが可能な請求項１８７に記載のシステム。
【請求項１９９】
中央脅威管理システムをさらに備え、前記中央脅威管理システムは複数のノード間電子通信脅威情報をコーディネートする請求項１８７に記載のシステム。
【請求項２００】
各アプリケーション層セキュリティ・システムは信頼されているアプリケーション層セキュリティ・システムである請求項１８７に記載のシステム。
【請求項２０１】
前記システム・プロセッサは脅威の統計を含む情報を出力する請求項１８７に記載のシステム。
【請求項２０２】
前記脅威の統計はある種の脅威の頻度に関する情報を出力する請求項２０１に記載のシステム。
【請求項２０３】
前記システム・プロセッサは特定の識別された脅威、１つ以上のホワイトリスト、トラフィック・パターン・データ、またはこれらの組み合わせを含む情報を出力する請求項１８７に記載のシステム。
【請求項２０４】
電子通信のバックトレールを特定する方法であって、
ａ）宛先アドレスを含む電子通信を受信する工程と、
ｂ）ソースから宛先アドレスへの経路内の１つ以上のコンピュータ・システム・アドレスを特定する工程と、
ｃ）前記特定されたコンピュータ・システムの少なくとも１つのアドレスの認証を分析する工程と、
ｄ）認証されたと分析された１つ以上のコンピュータ・システム・アドレスを出力する工程と
を含む方法。
【請求項２０５】
前記受信された電子通信は前記宛先アドレスを含むヘッダを備えると共に、１つ以上のアドレスを特定する工程はコンピュータ・システムのアドレスについて前記ヘッダをパーズする工程を含む請求項２０４に記載の方法。
【請求項２０６】
前記認証を分析する工程は前記ヘッダ内の不一致を識別する工程を含む請求項２０５に記載の方法。
【請求項２０７】
前記不一致を識別する工程は日付け情報、サーバー・バージョン情報、情報からの受信、受信者情報、またはそれらの組み合わせの不一致を識別する工程を含む請求項２０６に記載の方法。
【請求項２０８】
前記認証を分析する工程はヘッダ、前記通信に関連する転送情報、前記通信のコンテンツ、またはそれらの組み合わせの不一致を識別する工程を含む請求項２０５に記載の方法。
【請求項２０９】
前記認証を分析する工程は前記特定された各コンピュータ・システム・アドレスの認証を分析する工程を含む請求項２０４に記載の方法。
【請求項２１０】
前記認証を分析する工程はアドレス確認情報の外部データベースにアクセスする工程を含む請求項２０４に記載の方法。
【請求項２１１】
前記外部データベースは判明しているスパム発信者のＩＰアドレスまたはＡＳＮ番号を含む請求項２１０に記載の方法。
【請求項２１２】
前記アドレス確認情報はＩＰアドレス、ＡＳＮ番号、ホストネーム、ドメインネーム、ｅ−メール・アドレス、またはそれらの組み合わせを含む請求項２１０に記載の方法。
【請求項２１３】
前記認証を分析する工程は前記少なくとも１つの特定されたコンピュータ・システム・アドレスに基づいてＤＮＳ参照を実行する工程を含む請求項２０４に記載の方法。
【請求項２１４】
前記認証を分析する工程は前記少なくとも１つの特定されたコンピュータ・システム・アドレスの各々に信頼度レベルを割り当てる工程を含む請求項２０４に記載の方法。
【請求項２１５】
前記少なくとも１つの特定されたコンピュータ・システム・アドレスの各々に信頼度レベルを割り当てる工程は、特定されたコンピュータ・システム・アドレスの各々に信頼度レベルを割り当てる工程を含む請求項２１４に記載の方法。
【請求項２１６】
前記認証を分析する工程はさらに、前記割り当てられた信頼度レベルと所定の閾値とを比較する工程を含む請求項２１４に記載の方法。
【請求項２１７】
前記出力工程はさらに、認証が確認された各コンピュータ・システム・アドレスに関連する前記信頼度レベルを出力する工程を含む請求項２１４に記載のシステム。記載の方法。
【請求項２１８】
認証されないものと分析されたコンピュータ・システム・アドレスを出力する工程をさらに含む請求項２０４に記載の方法。
【請求項２１９】
電子通信のバックトレールを特定するシステムであって、
ａ）前記システムを通信ネットワークにリンクするようにされたインターフェースと、
ｂ）１つ以上の電子通信、これに関連するデータ、構成データ、またはそれらの組み合わせを記憶可能なシステム・データ・ストアと、
ｃ）前記インターフェースおよび前記システム・データ・ストアと通信し、１つ以上の処理要素を備え、前記１つ以上の処理要素は、
ｉ）前記インターフェースを介して通信を受信し、前記受信された通信は宛先アドレスを有するヘッダを含み、
ｉｉ）前記受信した脅威情報を前記システム・データ・ストアに記憶し、
ｉｉｉ）ソースと前記宛先アドレスとの間の経路内でコンピュータ・システムの１つ以上のアドレスについて前記受信された通信の前記ヘッダをパーズし、
ｉｖ）前記１つ以上のアドレスの各々にテストを実施して、各アドレスに信頼度の値を割り当て、
ｖ）割り当てられた信頼度の値と前記システム・データ・ストア内の所定の閾値とを比較することによって各アドレスが妥当であるか否かを判定し、かつ、
ｖｉ）妥当であると判定された各アドレスを出力するようにプログラムされ、または適応化されているシステム。
【請求項２２０】
前記システム・プロセッサは妥当であると判定された各アドレスを第一表示と共に出力する請求項２１９に記載のシステム。
【請求項２２１】
前記システム・プロセッサはさらに、妥当であると判定されない各アドレスを第二表示と共に出力するようにプログラムされ、または適応化されている請求項２２０に記載のシステム。
【請求項２２２】
電子通信のバックトレールを特定するシステムであって、
ａ）通信手段を経て送信された通信を受信するインターフェース手段と、
ｂ）１つ以上の受信された通信、これに関連するデータ、構成データ、またはそれらの組み合わせを記憶するための記憶手段と、
ｃ）受信された通信のソースと前記受信された通信の宛先との間の経路に沿った１つ以上のアドレスを受信された通信から特定する特定手段と、
ｄ）信頼度の値を各アドレスに割り当てる手段、および各アドレスに割り当てられた前記信頼度の値と前記記憶手段内の所定の閾値とを比較する手段を含む、前記特定手段に
よって特定された各アドレスを確認する確認手段と、
ｅ）妥当であると判定されたアドレスを出力する手段と
を備えるシステム。
【請求項２２３】
システム・プロセッサによって実行されると、システム・プロセッサが下記の工程、すなわち
ａ）前記インターフェースを介して通信を受信し、前記受信された通信は宛先アドレスを有するヘッダを含み、
ｂ）前記受信した脅威情報を前記システム・データ・ストアに記憶し、
ｃ）ソースと前記宛先アドレスとの間の経路内でコンピュータ・システムの１つ以上のアドレスについて前記受信された通信の前記ヘッダをパーズし、
ｄ）前記１つ以上のアドレスの各々にテストを実施して、各アドレスに信頼度の値を割り当て、
ｅ）割り当てられた信頼度の値と前記システム・データ・ストア内の所定の閾値とを比較することによって各アドレスが妥当であるか否かを判定し、かつ、
ｆ）妥当であると判定された各アドレスを出力する工程
を実施することによって電子通信用のバックトレールを特定するようにさせる命令を記憶するコンピュータ読み出し可能媒体。
【請求項２２４】
アプリケーション層セキュリティ・システム、脅威管理センター、またはアプリケーション・クライアント内の、またはこれらと通信する脅威プッシュバック・システムであって、
ａ）前記システムを通信ネットワークに通信可能に結合するインターフェースと、
ｂ）電子通信および受信された１つ以上の電子通信に関連する累積データを記憶可能であるシステム・データ・ストアと、
ｃ）前記システム・データ・ストアおよび前記インターフェースと通信するシステム・プロセッサとを備え、前記システム・プロセッサは１つ以上の処理要素を備えると共に、前記システム・プロセッサは、
ｉ）前記インターフェースを介して通信を受信し、
ｉｉ）前記受信された通信に関連する脅威プロファイルを作成し、
ｉｉｉ）前記受信された通信に関連する作成された脅威プロファイルを前記システム・データ・ストア内に記憶し、
ｉｖ）前記作成された脅威プロファイルを脅威構成情報と比較し、
ｖ）前記比較によって前記受信された通信が脅威を表していることが示されると、
１）前記受信された通信の戻り経路内の１つ以上のコンピュータ・アドレスを判定し、
２）前記記憶された脅威プロファイルに基づいて情報を前記１つ以上の判定されたアドレスに関連する１つ以上の上流のコンピュータへと出力する
システム。
【請求項２２５】
前記システム・プロセッサは前記受信された通信に１つ以上のテストを課すことによって前記脅威プロファイルを作成し、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された電子通信を評価する請求項２２４に記載のシステム。
【請求項２２６】
前記システム・プロセッサは、前記課せられた１つ以上のテストおよび前記システム・データ・ストアから前記受信された通信に関連する累積データに基づいて、前記受信された通信に関して異常が存在するか否かをさらに判定することによって、前記脅威プロファイルを作成する請求項２２５に記載のシステム。
【請求項２２７】
前記システム・プロセッサはさらに脅威の種類を特定するインターフェースを供給し、前記供給されたインターフェースから脅威の種類の情報を受信し、前記受信した脅威の種類の情報に基づいて前記システム・データ・ストア内の脅威構成情報を更新する請求項２２４に記載のシステム。
【請求項２２８】
前記システム・プロセッサはビジネスｅ−メール、個人ｅ−メール、チェーン・メール、アダルト言語、ポルノ、ウエブ製品の提供、ニューズレター、メーリング・リスト、ウォーム、ウイルスおよびサーバー攻撃、およびそれらの組み合わせを含む脅威の種類を特定するためのインターフェースを供給する請求項２２７に記載のシステム。
【請求項２２９】
前記システム・プロセッサは、脅威の種類を特定し、特定された各脅威の種類に関連する重みを指定可能にするインターフェースを供給する請求項２２７に記載のシステム。
【請求項２３０】
前記システム・プロセッサは前記脅威プロファイルから脅威値を計算することによって前記作成された脅威プロファイルと脅威強制情報とを比較し、前記脅威値が所定の脅威条件を満たすか否かを判定する請求項２２４に記載のシステム。
【請求項２３１】
前記システム・プロセッサは、前記脅威プロファイルから前記構成データ内の脅威の種類に関する重みと、それぞれの脅威の種類に関連する脅威の種類の値とを検索することによって前記脅威の値を計算し、前記検索された重みおよび脅威の種類の値に基づいて重み付き総計を生成する請求項２３０に記載のシステム。
【請求項２３２】
前記システム・プロセッサは所定の脅威条件に基づいて重みと数値とを検索する脅威の種類を選択することによって前記脅威の値を計算する請求項２３１に記載のシステム。
【請求項２３３】
前記システム・プロセッサはコンピュータ・アドレスを特定するためコンピュータ・システム・アドレス用の前記受信された通信に関連するヘッダを少なくともパーズすることによって、１つ以上の戻り経路コンピュータ・アドレスを判定する請求項２２４に記載のシステム。
【請求項２３４】
前記システム・プロセッサは前記少なくとも１つの特定されたコンピュータ・システム・アドレスの認証を少なくとも分析することによって、１つ以上の戻り経路コンピュータ・アドレスを判定する請求項２３３に記載のシステム。
【請求項２３５】
前記システム・プロセッサはさらに、セキュリティのデータベースを参照することによって、判定されたアドレスを上流のコンピュータへとマッピングするようにプログラムされ、または適応化されている請求項２２４に記載のシステム。
【請求項２３６】
前記システム・プロセッサは前記記憶された脅威プロファイルに基づいて情報を１つ以上の上流の脅威管理コンピュータ、１つ以上の上流のアプリケーション層セキュリティ・システム、またはその組み合わせに出力する請求項２２４に記載のシステム。
【請求項２３７】
前記システム・プロセッサは情報を１つ以上の上流のコンピュータ、１つ以上の脅威の種類、１つ以上の脅威ソース識別子、１つ以上の脅威の詳細、１つ以上の応答の詳細、またはそれらの組み合わせに出力する請求項２２４に記載のシステム。
【請求項２３８】
前記システム・プロセッサは情報を１つ以上の上流のコンピュータ、または１つ以上の脅威源識別子に出力し、各ソース識別子はｅ−メール・アドレス、ドメインネーム、ホストネーム、ＩＰアドレスまたはそれらの組み合わせである請求項２３７に記載のシステム。
【請求項２３９】
各ソース識別子は関連する信頼度の値を含んでいる請求項２３８に記載のシステム。
【請求項２４０】
前記システム・プロセッサは標準化された脅威情報プロトコルに従って情報を出力する請求項２２４に記載のシステム。
【請求項２４１】
前記システム・プロセッサはＳＮＭＰ、侵入検出メッセージ交換フォーマット（ＩＤＭＥＦ）、および侵入検出交換プロトコル（ＩＤＸＰ）からなる群から選択されたプロトコルに従って情報を出力する請求項２４０に記載のシステム。
【請求項２４２】
前記システム・プロセッサはさらに、前記比較によって前記受信された通信が脅威を表していることが示されると、脅威通知を出力するようにプログラムされ、または適応化されている請求項２２４に記載のシステム。
【請求項２４３】
前記システム・プロセッサは前記脅威通知を１つ以上のコンピュータ・システムに出力する請求項２４２に記載のシステム。
【請求項２４４】
前記システム・プロセッサは前記脅威通知をｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、ＳＮＭＰ警報、またそれらの組み合わせとして出力する請求項２４２に記載のシステム。
【請求項２４５】
前記システム・プロセッサはさらに、前記比較によって前記受信された通信が脅威を表していることが示されると、修正手段を講じるようにプログラムされ、または適応化されている請求項２２４に記載のシステム。
【請求項２４６】
前記修正手段は通知を１人以上のユーザーに伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによって管理可能なレベルまで抑制することを含む請求項２４５に記載のシステム。
【請求項２４７】
前記修正手段は通知を１人以上のユーザーに伝達することを含み、前記通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む請求項２４６に記載のシステム。
【請求項２４８】
コンピュータ実装脅威プッシュバック方法であって、
ａ）１つ以上の脅威の種類に関する、対象となる脅威の種類およびこれに関連する重みとを含む構成情報を構築するためのインターフェースを供給する工程と、
ｂ）通信を受信する工程と、
ｃ）１つ以上のテストを前記受信された電子通信に課すことによって前記受信された通信に関連する脅威プロファイルを作成し、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された通信を評価する工程と、
ｄ）前記脅威プロファイルから脅威値を計算することによって前記作成された脅威プロファイルと脅威強制情報とを比較し、前記脅威値が所定の脅威条件を満たすか否かを判定する工程と、
ｅ）前記比較によって前記受信された通信が脅威を表していることが示されると、
ｉ）前記受信された通信の戻り経路内の１つ以上のコンピュータ・アドレスを判定し、
ｉｉ）前記少なくとも１つの判定されたコンピュータ・システム・アドレスの認証を分析し、
ｉｉｉ）修正手段を講じ、前記修正手段は通知を１人以上のユーザーに伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによって管理可能なレベルまで抑制することを含み、前記伝達される各通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含み、
ｉｖ）前記記憶された脅威プロファイルに基づいて情報を前記１つ以上の上流のアプリケーション層セキュリティ・システム、１つ以上の脅威管理システム、またはその組み合わせへと出力し、各上流のアプリケーション層セキュリティ・システム、または脅威管理システムは１つ以上の判定されたアドレスに関連している工程を含む方法。
【請求項２４９】
システム・プロセッサによって実行されると前記システム・プロセッサが下記の工程、すなわち、
ａ）１つ以上の脅威の種類に関する、対象となる脅威の種類およびこれに関連する重みとを含む構成情報を構築するためのインターフェースを供給する工程と、
ｂ）通信を受信する工程と、
ｃ）１つ以上のテストを前記受信された電子通信に課すことによって前記受信された通信に関連する脅威プロファイルを作成し、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された通信を評価する工程と、
ｄ）前記脅威プロファイルから脅威値を計算することによって前記作成された脅威プロファイルと脅威強制情報とを比較し、前記脅威値が所定の脅威条件を満たすか否かを判定する工程と、
ｅ）前記比較によって前記受信された通信が脅威を表していることが示されると、
ｉ）前記受信された通信の戻り経路内の１つ以上のコンピュータ・アドレスを判定し、
ｉｉ）前記少なくとも１つの判定されたコンピュータ・システム・アドレスの認証を分析し、
ｉｉｉ）脅威通知を１人以上のユーザーに出力し、出力された各通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含み、
ｉｖ）前記記憶された脅威プロファイルに基づいて情報を前記１つ以上の上流のアプリケーション層セキュリティ・システム、１つ以上の脅威管理システム、またはその組み合わせへと出力し、各上流のアプリケーション層セキュリティ・システム、または脅威管理システムは１つ以上の判定されたアドレスに関連している工程と
を実行することによって特定された脅威の上流の脅威情報を特定し、かつプッシュバックするようにさせる命令を記憶するコンピュータ読み出し可能媒体。
【請求項２５０】
アプリケーション層セキュリティ・システム、脅威管理センター、またはアプリケーション・クライアント内の、またはこれらと通信する脅威プッシュバック・システムであって、
ａ）１つ以上の脅威の種類に関する、対象となる脅威の種類およびこれに関連する重みとを含む構成情報を構築するための構成手段と、
ｂ）電子通信を受信するための受信手段と、
ｃ）１つ以上のテストを前記受信された電子通信に課すことによって前記受信された通信に関連する脅威プロファイルを作成する手段であって、前記１つ以上のテストは各々特定のセキュリティ・リスクに関して前記受信された通信を評価する手段と、
ｄ）前記脅威プロファイルから脅威値を計算することによって前記作成された脅威プロファイルと脅威強制情報とを比較し、前記脅威値が所定の脅威条件を満たすか否かを判定する手段と、
ｅ）前記受信された通信の戻り経路内の１つ以上のコンピュータ・アドレスを判定する戻り経路特定手段と、
ｆ）前記戻り経路特定手段からの前記少なくとも１つの判定されたコンピュータ・システム・アドレスを認証する認証手段と、
ｇ）前記記憶された脅威プロファイルに基づいて情報を前記１つ以上の上流のアプリケーション層セキュリティ・システム、１つ以上の脅威管理システム、またはその組み合わせへと出力するための出力手段であって、各上流のアプリケーション層セキュリティ・システム、または脅威管理システムは１つ以上の判定されたアドレスに関連している出力手段と、
ａ）修正手段を講じる手段であって、通知を１人以上のユーザーに伝達し、前記受信された通信のソースからのそれ以上の通信の受け取りを拒否し、前記受信された通信を隔離し、前記受信された通信から特定されたコンテンツを剥ぎ取り、または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによって管理可能なレベルまで抑制することを含み、前記伝達される各通知はｅ−メール・メッセージ、ページ、ファクシミリ、電話通話、ＳＭＳメッセージ、ＷＡＰ警報、またはＳＮＭＰ警報を含む修正手段と
を備えるシステム。
【請求項２５１】
通信ネットワークを経て送信される迷惑（ｕｎｓｏｌｉｃｉｔｅｄ）通信を検出するためのシステムであって、
ａ）前記システムを前記通信ネットワークに結合するインターフェースと、
ｂ）前記通信ネットワークを経て送信された通信に関連するデータ、および１つ以上のホワイトリストを記憶できるシステム・データ・ストアと、
ｃ）前記インターフェースおよび前記データ・ストアと通信するシステム・プロセッサとを備え、前記システム・プロセッサは１つ以上の処理要素を含み、前記システム・プロセッサは、
ｉ）前記インターフェースを経て通信を受信し、
ｉｉ）前記通信を少なくとも１つのホワイトリストと比較し、
ｉｉｉ）前記通信に基づいて少なくとも１つのホワイトリストを修正する
システム。
【請求項２５２】
前記システム・プロセッサは前記受信された通信から導出された少なくとも１つのホワイトリストを更新することによって少なくとも１つのホワイトリストを修正するようにプログラムされ、または適応化されている請求項２５１に記載のシステム。
【請求項２５３】
前記システム・プロセッサはさらに、インバウンドまたはアウトバウンド通信のトラフィック・パターンから導出されたデータで少なくとも１つのホワイトリストを更新することによって少なくとも１つのホワイトリストを修正するようにプログラムされ、または適応化されている請求項２５１に記載のシステム。
【請求項２５４】
前記システム・プロセッサはインバウンドまたはアウトバウンド通信のトラフィック・パターンから導出されたデータで少なくとも１つのホワイトリストを更新することによって少なくとも１つのホワイトリストを修正する請求項２５３に記載のシステム。
【請求項２５５】
前記システム・プロセッサは前記受信された通信に関連する宛先アドレスに対応する少なくとも１つのホワイトリストにエントリを加えることによって少なくとも１つのホワイトリストを修正するようにプログラムされ、または適応化されている請求項２５１に記載のシステム。
【請求項２５６】
前記システム・プロセッサはさらに受信された通信に信頼度レベルを割り当てるようにプログラムされ、または適応化されている請求項２５１に記載のシステム。
【請求項２５７】
前記システム・プロセッサはさらに、通信に信頼度レベルの表示を送出するようにプログラムされ、または適応化されている請求項２５６に記載のシステム。
【請求項２５８】
前記通信はインターネットを介して送信または受信される請求項２５１に記載のシステム。
【請求項２５９】
前記通信はｅ−メール通信である請求項２５８に記載のシステム。
【請求項２６０】
前記通信はｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信を含む請求項２５１に記載のシステム。
【請求項２６１】
前記システム・プロセッサはさらに、前記少なくとも１つのホワイトリストを修正するためのインターフェースを供給するようにプログラムされ、または適応化されている請求項２５１に記載のシステム。
【請求項２６２】
前記システム・プロセッサはさらに、前記供給されたインターフェースからの情報を受信システム・プロセッサ、かつ前記インターフェースから受信された情報に基づいて少なくとも１つのホワイトリストに変更を加えるようにプログラムされ、または適応化されている請求項２６１に記載のシステム。
【請求項２６３】
前記インターフェースは前記少なくとも１つのホワイトリストを手動編集する請求項２６１に記載のシステム。
【請求項２６４】
前記システム・プロセッサはさらに、１つ以上のテストを課すことによって受信された通信の配信可能性を判定するようにプログラムされ、または適応化されている請求項２５１に記載のシステム。
【請求項２６５】
配信できないと判定された受信された通信は隔離、破棄、または送出される請求項２６４に記載のシステム。
【請求項２６６】
前記システム・プロセッサはさらに、前記受信された通信が配信できると判定された場合はこれを配信用に送出するようにプログラムされ、または適応化されている請求項２６４に記載のシステム。
【請求項２６７】
前記システム・プロセッサは前記１つ以上のテストの各々を並行して課す請求項２６４に記載のシステム。
【請求項２６８】
前記システム・プロセッサは前記１つ以上のテストの各々を順次に課す請求項２６４に記載のシステム。
【請求項２６９】
前記システム・データ・ストアは構成情報を記憶すると共に、前記システム・プロセッサは前記システム・データ・ストアに記憶された構成情報に基づいて前記１つ以上のテストの各々を課す請求項２６４に記載のシステム。
【請求項２７０】
前記システム・プロセッサは信頼性のレベルを計算することによって配信可能性を判定する請求項２６４に記載のシステム。
【請求項２７１】
前記システム・プロセッサは信頼性のレベルを閾値レベルと比較することによって配信可能性を判定する請求項２７０に記載のシステム。
【請求項２７２】
前記システム・プロセッサはさらに、前記システム・データ・ストアに記憶されている構成情報に基づいて受信された通信を配信するか否かを判定する請求項２６４に記載のシステム。
【請求項２７３】
前記構成情報は通信の種類、信頼度情報、期間情報、またはそれらの組み合わせを含む請求項２７２に記載のシステム。
【請求項２７４】
前記システム・プロセッサはさらに、配信可能性を判定するために１つ以上のテストを選択するようにプログラムされ、または適応化されている請求項２６４に記載のシステム。
【請求項２７５】
前記システム・プロセッサは通信の種類、構成情報またはその組み合わせに基づいて１つ以上のテストを選択する請求項２７４に記載のシステム。
【請求項２７６】
前記システム・プロセッサはさらに、受信された通信を少なくとも１つのホワイトリストと比較すると共に、前記システム・プロセッサは前記比較に基づいて１つ以上のテストを選択するようにプログラムされ、または適応化されている請求項２７４に記載のシステム。
【請求項２７７】
前記システム・プロセッサはさらに、受信された通信を少なくとも１つのホワイトリストと比較すると共に、前記システム・プロセッサは前記比較に基づいて配信可能性の判定を選択的に避けるようにプログラムされ、または適応化されている請求項２６４に記載のシステム。
【請求項２７８】
通信ネットワークを経て送信される迷惑通信を検出する方法であって、
ａ）少なくとも１つのホワイトリストを手動的に修正するためのインターフェースを供給する工程と、
ｂ）ｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信からなる群から選択された種類のアウトバウンド通信を受信する工程と、
ｃ）前記受信されたアウトバウンド通信を記憶する工程と、
ｄ）前記受信されたアウトバウンド通信の宛先に基づいて少なくとも１つのホワイトリストにエントリを加え、またはこれを修正することによって少なくとも１つのホワイトリストを修正する工程と
を含む方法。
【請求項２７９】
ａ）インバウンド通信を受信する工程と、
ｂ）前記インバウンド通信を前記少なくとも１つのホワイトリストと比較する工程と、
ｃ）前記受信されたインバウンド通信に関連する種類、構成情報、ホワイトリスト比較、またはそれらの組み合わせに基づいて複数の信頼性レベルを選択する工程と、
ｄ）前記選択された複数の信頼性レベル・テストを課すことによって前記受信されたインバウンド通信の配信可能性を判定する工程と、
ｅ）前記判定された配信可能性に基づいて前記通信に信頼度レベルを割り当てる工程と、
ｆ）前記割り当てられた信頼度レベルに基づいて、前記受信された通信を隔離、破棄、または送出する工程と
を含む請求項２７８に記載の方法。
【請求項２８０】
通信ネットワークを経て送信される迷惑通信を検出するためのシステムであって、
ａ）電子通信を受信する手段と、
ｂ）前記受信された電子通信がインバウンドであるかアウトバウンドであるかを判定する方向判定手段と、
ｃ）前記受信された通信に基づいて前記少なくとも１つのホワイトリストにエントリを追加し、または既存のエントリを更新することによって、前記方向判定手段によってアウトバウンドであると判定された受信された通信に基づいて少なくとも１つのホワイトリストを更新するためのホワイトリスト修正手段と、
ｄ）
ｉ）前記受信されたインバウンド通信を前記少なくとも１つのホワイトリストと比較し、
ｉｉ）前記受信されたインバウンド通信に関連する種類、構成情報、ホワイトリスト比較、またはそれらの組み合わせに基づいて複数の信頼性レベルを選択し、
ｉｉｉ）前記判定された配信可能性に基づいて前記通信に信頼度レベルを割り当て、
ｉｖ）前記割り当てられた信頼度レベルに基づいて、前記受信された通信を隔離、破棄、または送出することによって
前記方向判定手段によってインバウンドであると判定された受信された通信を配列する通信配列手段と
を備えるシステム。
【請求項２８１】
システム・プロセッサによって実行されると前記システム・プロセッサが下記の工程、すなわち、
ａ）少なくとも１つのホワイトリストを手動的に修正するためのインターフェースを供給する工程と、
ｂ）ｅ−メール通信、ＨＴＴＰ通信、ＦＴＰ通信、ＷＡＩＳ通信、テルネット通信、またはゴーファー通信からなる群から選択された種類のアウトバウンド通信を受信する工程と、
ｃ）前記受信されたアウトバウンド通信を記憶する工程と、
ｄ）前記受信されたアウトバウンド通信の宛先に基づいて少なくとも１つのホワイトリストにエントリを加え、またはこれを修正することによって少なくとも１つのホワイトリストを修正する工程と
を実行することによって、受信されたアウトバウンド通信に基づいてホワイトリストを自動的に修正するようにさせる命令を記憶するコンピュータ読み出し可能媒体。
【請求項２８２】
電子通信のセキュア配信方法であって、
ａ）所定の受信者に配信するために通信ソースから電子通信を受信する工程と、
ｂ）複数の配信機構の優先順位に基づいて前記複数の配信機構から配信機構を選択する工程と、
ｃ）前記選択された配信機構を介して前記電子通信の前記所定の受信者への配信を試行する工程と
を含む方法。
【請求項２８３】
ｄ）複数の配信機構を決定する工程をさらに含む請求項２８２に記載の方法。
【請求項２８４】
前記複数の配信機構を決定する前記工程は、通信ソース、デフォールト構成、またはその組み合わせに基づいて前記複数の配信機構を決定する工程からなる請求項２８３に記載の方法。
【請求項２８５】
ｅ）前記決定された複数の配信機構の優先順序付けを行う工程をさらに含む請求項２８３に記載の方法。
【請求項２８６】
前記決定された複数の配信機構の優先順序付けを行う工程は、前記複数の配信機構中の各配信機構に関する格付けに基づいて実施される請求項２８５に記載の方法。
【請求項２８７】
前記格付けは配信効率、配信コスト、配信セキュリティ、およびそれらの組み合わせからなる群から選択された判断基準に基づくものである請求項２８６に記載の方法。
【請求項２８８】
前記複数の配信機構は各々、（ａ）インスタント・メッセージング、ＳＭＴＰ、ＨＴＴＰ、およびＦＴＰからなる群から選択された基本機構と、（ｂ）少なくとも１つのセキュリティ・オプションとを含み、配信機構の優先順序は各配信機構に関連する少なくとも１つのセキュリティ・オプションに基づくものである請求項２８２に記載の方法。
【請求項２８９】
前記優先順序付けは第一にセキュリティ・オプションとしてＳ／ＭＩＭＥを含む配信機構を、第二にセキュリティ・オプションとしてＰＧＰを含むがＳ／ＭＩＭＥではない配信機構を、また第三にセキュリティ・オプションとしてＴＬＳまたはＳＳＬを含むがＰＧＰでもＳ／ＭＩＭＥでもない配信機構を配置する請求項２８８に記載の方法。
【請求項２９０】
ｄ）前記所定の受信者に基づいて前記複数の配信機構の優先順序を検索する工程をさらに含む請求項２８２に記載の方法。
【請求項２９１】
各配信機構は関連する格付けを有すると共に、前記優先順序を検索する工程は、
１）前記所定の受信者に基づいて前記検索された通信の配信に利用できる配信機構を特定する工程と、
２）特定された各配信機構に関する格付けに基づいて前記特定された配信機構の優先順序付けを行う工程と
を含む請求項２９０に記載の方法。
【請求項２９２】
前記配信機構に関連する前記格付けは配信効率、配信コスト、配信セキュリティ、およびそれらの組み合わせからなる群から選択された判断基準に基づくものである請求項２９１に記載の方法。
【請求項２９３】
ｄ）前記通信ソースに基づいて前記複数の配信機構の優先順序を検索する工程をさらに含む請求項２８２に記載の方法。
【請求項２９４】
ｄ）前記複数の配信機構の優先順序を指定するためのインターフェースを通信ソースに供給する工程と、ｅ）前記供給されたインターフェースから前記優先順序を受信する工程とをさらに含む請求項２８２に記載の方法。
【請求項２９５】
ｄ）前記複数の配信機構の優先順序を指定するためのインターフェースを管理者に供給する工程と、ｅ）前記供給されたインターフェースから前記優先順序を受信する工程とをさらに含む請求項２８２に記載の方法。
【請求項２９６】
ｄ）配信に失敗すると、下記の工程、
１）前記複数の配信機構の前記優先順序に基づいて前記複数の配信機構からさらに別の配信機構を選択する工程、および、
２）前記さらに別の配信機構を介した前記所定の受信者への電子通信の配信を試行する工程
とによって、前記電子通信を前記所定の受信者に再配信することを試行する請求項２８２に記載の方法。
【請求項２９７】
前記受信された通信がセキュア配信を要求していることが判定されると、ｅ）前記受信された通信の配信に成功するまで、または前記複数の配信機構の中の利用可能な全ての配信機構が使い果たされるまで工程ｄ）を繰り返す工程をさらに含む請求項２９６に記載の方法。
【請求項２９８】
前記複数の配信機構は各々が基本機構を備えると共に、各基本機構はインスタント・メッセージング、ＳＭＴＰ、ＨＴＴＰ、およびＦＴＰからなる群から選択される請求項２８２に記載の方法。
【請求項２９９】
前記複数の配信機構の中の各ＳＭＴＰ配信機構はＳ／ＭＩＭＥ、ＰＧＰ、ＴＬＳ、ＳＳＬおよびそれらの組み合わせからなる群から選択されるセキュリティ・オプションを含む請求項２９８に記載の方法。
【請求項３００】
１つ以上のＳＭＴＰ配信機構はＳ／ＭＩＭＥ通知機構であると共に、前記セキュリティ・オプションはＳ／ＭＩＭＥ、ＨＴＴＰ−Ｓ、ＴＬＳ、ＳＳＬおよびそれらの組み合わせからなる群から選択された１つ以上の暗号化オプションを含むＨＴＴＰ提示である請求項２９８に記載の方法。
【請求項３０１】
前記ＳＭＴＰ通知機構のサブセットは前記ＳＭＴＰ通知に関連するさらに別のセキュリティ・オプションを含むと共に、前記さらに別のセキュリティ・オプションはＳ／ＭＩＭＥ、ＰＧＰ、ＴＬＳ、ＳＳＬおよびそれらの組み合わせからなる群から選択される請求項３００に記載の方法。
【請求項３０２】
ＨＴＴＰ提示セキュリティ・オプションはさらに１つ以上のユーザー認証要求を含む請求項３００に記載の方法。
【請求項３０３】
前記複数の配信機構中の各ＨＴＴＰ配信機構はＳ／ＭＩＭＥ、ＨＴＴＰ−Ｓ、ＴＬＳ、ＳＳＬおよびそれらの組み合わせからなる群から選択されたセキュリティ・オプションを含む請求項２９８に記載の方法。
【請求項３０４】
前記複数の配信機構中各ＦＴＰ配信機構はＴＬＳおよびＳＳＬからなる群から選択されたセキュリティ・オプションを含む請求項２９８に記載の方法。
【請求項３０５】
前記複数の配信機構は各々がメッセージ・レベル暗号化技術を利用する請求項２９８に記載の方法。
【請求項３０６】
前記複数の配信機構は各々がチャネル・レベル暗号化技術を利用する請求項２９８に記載の方法。
【請求項３０７】
前記複数の配信機構はさらに各々がメッセージ・レベル暗号化技術を利用する請求項３０６に記載の方法。
【請求項３０８】
ｄ）前記受信された通信がセキュア配信を要求しているか否かを判定する工程をさらに備えたと共に、工程ｂ）およびｃ）は、前記受信された通信がセキュア配信を要求しているものと判定されると実行される請求項２８２に記載の方法。
【請求項３０９】
前記受信された通信がセキュア配信を要求しているものと判定されると、ｅ）前記複数の配信機構の優先順序を指定し、かつｆ）前記供給されたインターフェースから前記優先順序を受信する工程をさらに含む請求項３０８に記載の方法。
【請求項３１０】
前記受信された通信がセキュア配信を要求しているか否かを判定する工程は、
ｉ）セキュア配信の要望を示すインデックスについて前記受信された通信をパーズし、
ｉｉ）前記パーシングに基づいて前記受信された通信がセキュア配信を要求していることを指定する工程を含む請求項３０８に記載の方法。
【請求項３１１】
前記パーシングに基づいて前記受信された通信がセキュア配信を要求いることを指定する工程は、１つ以上の所定のキーワードが前記受信された通信からパーズされると前記受信されたが通信セキュア配信を要求していることを特定する請求項３１０に記載の方法。
【請求項３１２】
前記パーシング工程は前記受信された通信内のヘッダ部分でだけ実施されると共に、前記パーシングに基づいて前記受信された通信がセキュア配信を要求していることを指定する工程は、１つ以上の所定のキーワードが前記ヘッダからパーズされると前記受信されたが通信セキュア配信を要求していることを特定する請求項３１０に記載の方法。
【請求項３１３】
セキュア配信の要望を示すインデックスについて前記受信された通信をパーズする前記工程は、前記受信された通信に１つ以上のフィルタリング・ルールを付与する工程を含む請求項３１０に記載の方法。
【請求項３１４】
前記１つ以上のフィルタリング・ルールは各々、コンテンツ・フィルタリング・ルール、添付フィルタリング・ルール、ソース・フィルタリング・ルール、または受信者フィルタリング・ルールである請求項３１３に記載の方法。
【請求項３１５】
前記受信された通信がセキュア配信を要求しているか否かを判定する工程は、管理者によって指定された構成に基づいて前記受信された通信がセキュア配信を指定する工程を含む請求項３０８に記載の方法。
【請求項３１６】
前記構成は１つ以上のフィルタリング・ルールを含み、このようなルールは各々がコンテンツ・フィルタリング・ルール、添付フィルタリング・ルール、ソース・フィルタリング・ルール、または受信者フィルタリング・ルール、およびこれらの組み合わせからなる群から選択された種類のルールである請求項３１５に記載の方法。
【請求項３１７】
電子通信をセキュア配信するためのシステムであって、
ａ）少なくとも１つの電子通信および複数の配信機構に関連する構成データを記憶可能であるシステム・データ・ストアと、
ｂ）前記システムと１つ以上のクライアント・アプリケーションとの通信をサポートする通信ネットワークへのインターフェースと、
ｃ）前記システム・データ・ストアおよび前記インターフェースと通信するシステム・プロセッサとを備え、前記システム・プロセッサは１つ以上の処理要素を備えると共に、前記１つ以上の処理要素は、
ｉ）前記インターフェースを介して所定の受信者に配信するために通信ソースから電子通信を受信し、
ｉｉ）前記受信された通信を記憶し、
ｉｉｉ）前記受信された通信がセキュア通信を要求しているか否かを前記受信された通信、前記所定の受信者、通信ソース、デフォールト構成、またはその組み合わせに基づいて判定し、
ｉｖ）前記受信された通信がセキュア通信を要求しているものと判定されると、
１）通信ソース、前記所定の受信者、デフォールト構成、またはその組み合わせに基づいて複数の配信機構を決定し、前記複数の配信機構は各々が基本機構および少なくとも１つのセ・オプションを備えると共に、各基本機構はインスタント・メッセージング、ＳＭＴＰ、ＨＴＴＰ、ＦＴＰ、およびＨＴＴＰ提示を伴うＳＭＴＰからなる群から選択され、各セキュリティ・オプションはチャネル・レベル暗号化、メッセージ・レベル暗号化、またはその組み合わせであり、
２）前記複数の配信機構の決定と同時に、またはその後でセキュリティが最も高い競合相手から最も低い競合相手に対応する順序で前記複数の配信機構中の配信機構の順序付けを行い、
３）前記優先順位に基づいて前記複数の配信機構から配信機構を選択し、
４）前記インターネット、または前記システムと第二通信ネットワークとの通信を可能にするインターフェースを利用して前記選択された配信機構を介して前記所定の受信者への前記電子通信の配信を試行し、
５）配信に失敗すると、
（ａ）前記複数の配信機構の前記優先順序に基づいて前記複数の配信機構からさらに別の配信機構を選択し、
（ｂ）前記さらに別の配信機構を介した前記所定の受信者への電子通信の配信を試行し、
（ｃ）前記複数の配信機構中の配信機構が使い果たされるまで（ａ）および（ｂ）を繰り返す
ようにプログラムされ、または適応化されたシステム。
【請求項３１８】
電子通信をセキュア配信するためのシステムであって、
ａ）前記システムと１つ以上のクライアント・アプリケーションとの通信を可能にするインターフェース手段と、
ｂ）１つ以上の通信および複数の配信機構に関連する構成データを記憶するのに充分な容量を備えた記憶手段と、
ｃ）インターフェース中断を介して通信を受信し、前記通信を前記記憶手段に記憶する手段と、
ｄ）受信された通信がセキュア通信を要求しているか否かを前記受信された通信、前記所定の受信者、前記通信ソース、デフォールト構成、またはその組み合わせに基づいて判定する判定手段と、
ｅ）配信手段と
を備え、前記配信手段は、
ｉ）前記受信された通信がセキュア通信を要求しているものと判定されると、通信ソース、前記所定の受信者、デフォールト構成、またはその組み合わせに基づいて複数の配信機構を決定し、前記複数の配信機構は各々が基本機構および少なくとも１つのセ・オプションを備えると共に、各基本機構はインスタント・メッセージング、ＳＭＴＰ、ＨＴＴＰ、ＦＴＰ、およびＨＴＴＰ提示を伴うＳＭＴＰからなる群から選択され、各セキュリティ・オプションはチャネル・レベル暗号化、メッセージ・レベル暗号化、またはその組み合わせであり、
ｉｉ）前記複数の配信機構の決定と同時に、またはその後でセキュリティが最も高い競合相手から最も低い競合相手に対応する順序で前記複数の配信機構中の配信機構の順序付けを行い、
ｉｉｉ）前記優先順位に基づいて前記複数の配信機構から配信機構を選択し、
ｉｖ）前記選択された配信機構を介して前記所定の受信者への電子通信の配信を試行し、
ｖ）配信に失敗すると、
１）前記複数の配信機構の前記優先順序に基づいて前記複数の配信機構からさらに別の配信機構を選択し、
２）前記さらに別の配信機構を介した前記所定の受信者への電子通信の配信を試行し、
３）前記複数の配信機構中の配信機構が使い果たされるまで１）および２）を繰り返す
ことによって前記電子通信の前記所定の受信者への配送を試行し、
ｆ）前記配信手段はチャネル・レベル暗号化、メッセージ・レベル暗号化、またはチャネルおよびメッセージ・レベルの暗号化を行う暗号化手段を備えるシステム。
【請求項３１９】
１つ以上の処理要素を備えたシステム・プロセッサによって実行されると、前記１つ以上の処理要素が下記の工程、すなわち、
ａ）所定の受信者に配信するために通信ソースからの電子通信を受信し、
ｂ）通信ソース、前記所定の受信者、デフォールト構成、またはその組み合わせに基づいて前記受信された通信がセキュア配信を要求しているか否かを判定し、
ｃ）前記受信された通信がセキュア通信を要求しているものと判定されると、
ｉ）通信ソース、前記所定の受信者、デフォールト構成、またはその組み合わせに基づいて複数の配信機構を決定し、前記複数の配信機構は各々が基本機構および少なくとも１つのセキュリティ・オプションを備えると共に、各基本機構はインスタント・メッセージング、ＳＭＴＰ、ＨＴＴＰ、ＦＴＰ、およびＨＴＴＰ提示を伴うＳＭＴＰからなる群から選択され、各セキュリティ・オプションはチャネル・レベル暗号化、メッセージ・レベル暗号化、またはその組み合わせであり、
ｉｉ）前記複数の配信機構の決定と同時に、またはその後でセキュリティが最も高い競合相手から最も低い競合相手に対応する順序で前記複数の配信機構中の配信機構の順序付けを行い、
ｉｉｉ）前記優先順位に基づいて前記複数の配信機構から配信機構を選択し、
ｉｖ）前記選択された配信機構を介して前記所定の受信者への電子通信の配信を試行し、
ｖ）配信に失敗すると、
１）前記複数の配信機構の前記優先順序に基づいて前記複数の配信機構からさらに別の配信機構を選択し、
２）前記さらに別の配信機構を介した前記所定の受信者への電子通信の配信を試行し、
ｖｉ）前記複数の配信機構中の配信機構が使い果たされるまで工程（ｖ）を繰り返す
ことによって前記電子通信の前記所定の受信者への配送を試行する
工程を実行することによって電子通信をセキュア配信するようにさせる命令を含むコンピュータ読み出し可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
(関連出願の相互参照)
本出願は２００３年２月７日に出願された米国特許出願第１０／３６１，０９１号および１０／３６１，０６７号、および全て２００２年３月８日に出願された米国特許出願第１０／０９３，５５３号、１０／０９４，２１１号、および１０／０９４，２６６号に対する優先権を主張し、それらの内容を参照によって本明細書に組み込む。
【背景技術】
【０００２】
(背景技術)
本発明は電子通信に関連するセキュリティを強化するシステムおよび方法に対するものである。より具体的には、本発明は、それに限定されるものではないが、通信ネットワークを経て送信される電子通信に関連するセキュリティ・リスクを査定するためのコンピュータ・ベースのシステムおよび方法に関するものである。さらに、本発明はある実施形態では、通信ネットワークを経て送信される電子通信に関連するセキュリティ・リスクを査定し、且つメッセージ・システムに対する脅威の範囲に応答するためのコンピュータ・ベースのシステムおよび方法に関するものである。
【０００３】
インターネットは接続されたコンピュータ・ネットワークのグローバルなネットワークである。ここ数年来、インターネットは膨大に成長してきた。膨大な数のコンピュータがインターネット上で多様な形式の情報を提供している。インテーネットに接続されたコンピュータを持っていれば潜在的には誰でもこの膨大な情報プールを利用できる。
【０００４】
インターネットを入手できる情報には、ＳＭＴＰ（簡易メール転送プロトコル）、ＰＯＰ３（ポストオフィス・プロトコル）、ＧＯＰＨＥＲ（ＲＦＣ１４３６）、ＷＡＩＳ、ＨＴＴＰ（ハイパーテキスト転送プロトコル、ＲＦＣ２６１６）およびＦＴＰ（ファイル転送プロトコル、ＲＦＣ１１２３）のような多様な種類のアプリケーション層情報サーバーを介して入手可能な情報が含まれる。
【０００５】
インターネットを経て情報を提供する最も普及している方法はワールドワイドウエブ（Ｗｅｂ）を介した方法である。Ｗｅｂはインターネットに接続されたコンピュータのサブセットから構成されている。このサブセット内のコンピュータはハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバー（Ｗｅｂサーバー）を実行する。例えば拡張フレームワーク（ＲＦＣ２７７４）およびユーザー間認証（ＲＦＣ２６１７）を含め、ＨＴＴＰへの幾つかの拡張および修正が提案されている。インターネット上の情報は統一資源識別子（ＵＲＩ、ＲＦＣ２３９６）を介してアクセス可能である。ＵＲＩはインターネット上の特定の情報部分のロケーションを一意的に特定する。ＵＲＩは典型的には幾つかの構成要素から構成される。第一の構成要素は典型的には情報のアドレス部分がアクセスされるプロトコル（例えばＨＴＴＰ、ＧＯＰＨＥＲなど）を指定する。この第一の構成要素はコロン（‘：’）によって残りのＵＲＩから分離されている。残りのＵＲＩはプロトコルの構成要素に依存する。典型的には、残りのＵＲＩは名前、またはＩＰ名、ならびに指定されたコンピュータ上のリソースのロケーションのさらに特定された呼称によってインターネット上のコンピュータを指定する。例えば、ＨＴＴＰリソース用の典型的なＵＲＩには、
ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ｄｉｒ２／ｒｅｓｏｕｒｃｅ．ｈｔｍ
があるだろう。ここでｈｔｔｐはプロトコルであり、ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍは指定されたコンピュータであり、ｄｉｒ２／ｒｅｓｏｕｒｃｅ．ｈｔｍは指定されたコンピュータ上のリソースのロケーションである。ＵＲＩという用語はＲＦＣ２１４１にしたがって定義されたＵＲＮを含む統一資源名（ＵＲＮ）を含む。
【０００６】
Ｗｅｂページの形式のＷｅｂサーバー・ホスト情報；ホスト・サーバーおよびホスト情報は全体としてＷｅｂサイトと呼ばれる。その他のエンコードには拡張可能なマークアップ言語（ＸＭＬ）またはＸＨＴＭＬを利用しているものもあるが、相当数のＷｅｂページはハイパーテキスト・マークアップ言語（ＨＴＭＬ）を利用してエンコードされる。これらの言語の公刊された規格は参照によって本明細書に組み込まれている。このような規格はワールドワイドウエブのコンソーシアムおよびそのＷｅｂサイト（ｈｔｔｐ：／／ｗｗｗ．ｗ３ｃ．ｏｒｇ）から入手できる。これらの書式化言語内のＷｅｂページは同じＷｅｂサイト、または別のＷｅｂサイト上の別のＷｅｂページへのリンクを含んでいてもよい。当業者には知られているように、ＷｅｂページはＷｅｂクライアントに送信される前に、書式化されたページに多様な要素を組み込むことによってサーバーがダイナミックに作成できる。Ｗｅｂサーバー、および他の種類の情報サーバーはインターネットのクライアントからの情報要求を待機する。
【０００７】
インターネットに接続されたコンピュータのユーザーがこの情報にアクセスできるようにするクライアント・ソフトウエアが進化を遂げている。ネットスケープのナビゲータ、およびマイクロソフトのインターネット・エクスプローラのような高度なクライアントによって、ユーザーは統一クライアント環境での多様な情報サーバーを介して提供されるソフトウエアにアクセスできる。典型的には、このようなクライアント・ソフトウエアはブラウザ・ソフトウエアと呼ばれる。
【０００８】
電子メール（ｅ−メール）はインターネットを利用してもう１つの広く普及したアプリケーションである。前記のＳＭＴＰおよびＰＯＰ３／ＭＡＰＩ（メッセージ・アプリケーション・プログラミング・インターフェース）を含む多様なプロトコルがｅ−メールの送信、配信、および処理に利用されることが多い。これらのプロトコルはそれぞれ、ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）によって普及された特定のＲＦＣ（コメント・要求）で定義されている。ＳＭＴＰプロトコルはＲＦＣ８２１および８２２で定義され、ＰＯＰ３プロトコルはＲＦＣ１９３９で定義されている。ＭＡＰＩはＰＯＰ３プロトコルを介して提供されるよりも高レベルのメール可能アプリケーション用の通信および組織化を可能にするためにマイクロソフト（マイクロソフト・コーポレーション、ワシントン州レッドモンド）によって開発されたプロトコルである。ＭＡＰＩ用のレファレンス・マニュアルはマイクロソフトのオンライン・レファレンス・マニュアルを経て見出される（ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／）。加えて、ＩＭＡＰプロトコルはｅ−メール・サーバーとクライアントとのさらに高度なインタラクションをサポートするため、ＰＯＰ３の代替として進化したものである。このプロトコルはＲＦＣ２０６０に記載されている。
【０００９】
これらの標準規格の発足以来、ｅ−メールの分野では様々なニーズが発生し、それらが、強化された、または付加的なプロトコルを含むさらなる規格の開発をもたらしてきた。拡張の例は（１）サーバーＳＭＴＰがサポートするサービスの拡張に関してクライアントＳＭＴＰに情報伝達できる手段を定義することによってＳＭＴＰを拡張するためのフレームワークを定義するＲＦＣ１８６９、（２）ＳＭＴＰクライアントが（ａ）ある条件下で配信状態通知（ＤＳＮ）が作成されるべきであること、（ｂ）このよう通知がメッセージのコンテンツを返送すべきか否か、（ｃ）およびＤＳＮの交付先である受信者（単数または複数）およびオリジナル・メッセージが送信されたトランザクションの双方を送信者が特定できるようにする、ＤＳＮと共に返送される追加情報を指定できるようにするＳＭＴＰへの拡張を定義するＲＦＣ１８９１に見出すことができる。
【００１０】
ＨＴＴＰおよびＳＭＴＰの双方とも、公開（暗号化されない）チャネルを経た標準構造の通信メッセージで通信する。送信のセキュリティを強化するため、様々な技術的進展がなされてきた。これらの双方のプロトコル用に２つの暗号化が開発された。すなわちチャネルの暗号化とメッセージの暗号化である。チャネルの暗号化は、確立された暗号化を利用して任意の量のデータを通信可能なセキュア・チャネルを確立する。メッセージの暗号化は個々のメッセージの暗号化を確立し、これらはその後、特定のチャネルを経て送出される。これらのアプローチを組み合わせて、２つのレベルの暗号化、すなわち一方はチャネル・レベル、他方はメッセージ・レベルで暗号化することが可能になる。
【００１１】
ＨＴＴＰ用には、特定形式のメッセージ・レベルの暗号化がＳ−ＨＴＴＰと呼ばれる規格として採用されてきた。このプロトコルの規格はＲＦＣ２６６０に記載されている。ＨＴＴＰはＭＩＭＥ（多目的インターネット・メール拡張）規格（ＲＦＣ）に従ってデータもサポート通信を要求し、これに応答する。これのセキュリティ強化バージョンが実施されており、Ｓ／ＭＩＭＥ（セキュア／多目的インターネット・メール拡張）と呼ばれている。このセキュリティ強化バージョンはさらにメッセージ・レベルの暗号化の手段をも提供する。Ｓ／ＭＩＭＥの具体的な詳細はＲＦＣ２３１１および２６３３に記載されている。Ｓ／ＭＩＭＥの利用をめぐる追加の詳細は、それらに限定されるものではないが、ＲＦＣ２３１２、２６３２、２６３４、２７８５−６、２９８４、３０５８、３１１４、３１２５−６、３１８３、３１８５、３２１１、３２１７−８、３２７４、３２７８、３３６９−７０、および３３９４を含む他の様々なＲＦＣに定義されている（現在のＳ／ＭＩＭＥに関するさらなる詳細はＩＥＴＦのＳ／ＭＩＭＥのチャーター・ホームページであるｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｓｍｉｍｅ−ｃｈａｔｅｒ．ｈｔｍｌ）で見出される。
【００１２】
チャネル・レベルの暗号化用には、ネットスケープ・コミュニケーションズによる初期の開発によってＳＳＬ（セキュア・ソケット層）プロトコルが導入された。バージョン３．０のドキュメンテーションはｈｔｔｐ：／／ｗｐ．ｎｅｔｓｃａｐｅ．ｃｏｍ／ｅｎｇ／ｓｓｌ３／ｓｓｌ−ｔｏｃ．ｈｔｍｌで見出すことができる。このチャネル暗号化メカニズムは一般に利用されており、ＵＲＬはｈｔｔｐ：ではなくｈｔｔｐｓ：を用いてこのプロトコルを利用することを示している。ＳＳＬと後方互換性があるようにしたより新しい技術はＴＬＳ（トランスポート層セキュリティ）である。その完全な説明はＲＦＣ２２４６に記載されている。ＴＬＳをめぐるその他の詳細は、それらに限定されるものではないが、ＲＦＣ２７１２、２８１７−８、および３２６８を含む他のさまざまなＲＦＣで定義されている。（ＴＬＳの現時点での開発のさらなる詳細はＩＥＴＦのＳ／ＭＩＭＥのチャーター・ホームページであるｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ．ｃｈａｒｔｅｒｓ／ｓｍｉｍｅ−ｃｈａｔｅｒ．ｈｔｍｌ）で見出される。
【００１３】
ＳＭＴＰ用には、同様の技術が適用されてきた。メッセージ・レベルの暗号化には様々な形式の公開鍵暗号化技術が利用されてきた。最も広範に利用されている公開鍵の１つはＰＧＰ（プリティグッドプライバシー）と呼ばれる。ＳＭＴＰ配信メッセージと組み合わせてＳ／ＭＩＭＥを利用することもできる。ＨＴＴＰと同様に、チャネル・レベル暗号化メカニズムとしてＳＳＬまたはＴＬＳを利用することも可能である。さらに、チャネル暗号化、および１つ以上のメッセージ暗号化の双方をセキュアＳＭＴＰ配信と組み合わせて利用することもできる。
【００１４】
上記のさまざまな標準規格はあらゆる目的のため参照によって本明細書に組み込まれている。ＲＦＣによって言及されている規格はＩＥＴＦを介して公に利用され、Ｗｅｂサイトから検索できる（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｅｃ．ｈｔｍｌ）。特定されたプロトコルは上記に引用された特定のＲＦＣに限定するものではなく、その拡張および改訂を含めるものである。このような拡張および／または改訂は現在および／または将来のＲＦＣに含めても含めなくてもよい。
【００１５】
インターネットを経たｅ−メールを促進するため、多数のｅ−メール・サーバーおよびクライアント製品が開発されている。ｅ−メール・サーバー・ソフトウエアにはセンドメール・ベースト・サーバー、マイクロソフト交換、ロータス・ノート・サーバーおよびノーベルグループワイズのような製品が含まれる。センドメール・ベースト・サーバーは元来ＵＮＩＸ（登録商標）オペレーティングシステム用に開発されたセンドメール・プログラムに基づく幾つかのサーバーのバリエーションのことである。ユーザーがサーバーからのｅ−メール・メッセージを検索し、閲覧できるようにするため多数のｅ−メール・クライアントが開発されてきた。製品の例にはマイクロソフトのアウトルック、マイクロソフトのアウトルック・エキスプレス、ネットスケープ・メッセンジャー、およびＥｕｄｏｒａが含まれる。加えて、ある種のｅ−メール・サーバーまたはｗｅｂサーバーと連携したｅ−メール・サーバーによってＷｅｂブラウザはＨＴＴＰ規格を利用してｅ−メール・クライアントとしての役割を果たすことができる。
【００１６】
インターネットはより広範に利用されるようになってきたので、企業にとっての新たなリスクも生じている。ハッカーや侵入者によるコンピュータ・セキュリティの侵害、および機密の企業情報を脅かす可能性は極めて現実的で深刻な脅威である。組織はそのネットワークをインターネット攻撃から防護するために下記の技術の一部または全てを実施してきた。
【００１７】
ファイヤウォールは企業ネットワークの周辺で配備されてきた。ファイヤウォールは門番としての役割を果たし、認可されたユーザーだけが会社のネットワークにアクセスすることを許可する。ファイヤウォールはネットワークへのトラフィックを制御する上で重要な役割を果たし、インターネット・セキュリティを備えるための第一歩である。
【００１８】
侵入検知システム（ＩＤＳ）は企業ネットワーク全体を通して配備されている。ファイヤウォールが門番としての役割を果たすのに対して、ＩＤＳはビデオカメラのように動作する。ＩＤＳはネットワーク・トラフィックの不審な活動パターンを監視し、そのような活動が検出されると警報を発する。ＩＤＳは企業内、またはその他のローカル・ネットワーク内の侵入者を特定するために、あなたのネットワークを事前に２４時間監視する。
【００１９】
ファイヤウォールおよびＩＤＳは企業が自らのネットワークを保護し、企業情報資産を防御することを補助してきた。しかし、これらのデバイスの利用が広範にわたっているので、ハッカーは適応化し、現在では標的をネットワークからインターネット・アプリケーションへとシフトしてきている。最も無防備なアプリケーションはウエブおよびｅ−メールのようなインターネットとの直接の“常開”接続を必要とするアプリケーションである。その結果、侵入者はこれらのアプリケーション内のセキュリティ・ホールを標的にした精巧な攻撃に乗り出している。
【００２０】
多くの企業は企業のコンピュータ・ネットワークから出入りするトラフィックの流れを制御する１つの手段としてネットワーク・ファイヤウォールをインストールしてきたが、ｅ−メール・メッセージやＷｅｂ要求および応答のようなインターネット・アプリケーション通信となると、企業は従業員が社内外の誰から（へ）の、またはどこから（へ）の通信をも送受信することを許容している場合が多い。これはトラフィックの流れを可能にするためにファイヤォールのポートまたはホール（典型的にはｅ−メールの場合はポート２５、またＷｅｂの場合はポート８０）を開くことによって行われる。ファイヤウォールはこのポートを経たトラフィックの流れを精査することはない。これは、会社の入口にセキュリティ・ガードを配備してはいるが、サービス要員に見える誰かがビルに入ることができることと同様である。侵入者はサービス要員であると見せかけ、周辺セキュリティを回避し、供給されているインターネット・アプリケーションを損なうことができる。
【００２１】
図１は典型的な従来のサーバー・アクセス・アーキテクチャを示している。企業のローカル・ネットワーク１９０内に多様なコンピュータ・システムが存在する。これらのシステムには典型的には、Ｗｅｂサーバーおよびｅ−メール・サーバーのようなアプリケーション・サーバー１２０、ｅ−メール・リーダーおよびＷｅｂブラウザのようなローカル・クライアント１３０を実行するワークステーション、およびデータベースおよびネットワーク接続ディスクのようなデータ記憶デバイス１１０が含まれる。これらのシステムはイーサーネット１５０のようなローカル通信ネットワークを介して互いに通信する。ローカル通信ネットワークとインターネット１６０との間にはファイヤウォール・システム１４０が存在する。インターネット１６０には多数の外部サーバー１７０と外部クライアント１８０が接続されている。
【００２２】
ローカル・クライアント１３０はローカル通信ネットワークを経てアプリケーション・サーバー１２０および共用データ記憶装置１１０にアクセスすることができる。外部クライアント１８０はインターネット１６０を経て外部アプリケーション・サーバー１７０にアクセスすることができる。ローカル・サーバー１２０またはローカル・クライアント１３０が外部サーバー１７０へのアクセスを要求するか、または外部クライアント１８０または外部サーバー１７０がローカル・サーバー１２０へのアクセスを要求する場合、所定のアプリケーション・サーバー用の適宜のプロトコル内の電子通信がファイヤウォール・システム１４０の“常開”ポートを通って流れる。
【００２３】
そこでセキュリティのリスクは止まらない。メール・サーバーを乗っ取った後は、侵入者にとってはこれを他のビジネス・サーバーを脅かし、重要なビジネス情報を盗むためのランチパッドとして利用することは比較的容易である。この情報には財務データ、販売プロジェクト、顧客パイプライン、契約交渉、法的案件、およびオペレーション・ドキュメントが含まれる。ハッカーによるサーバーに対するこの種類の攻撃によって、ビジネスに計り知れない、また修復不能な損失が生ずることがある。
【００２４】
１９８０年代、主としてフロッピー（登録商標）ディスクによってウイルスが蔓延した。今日の相互に接続された世界では、ｅ−メールのようなアプリケーションは容易に、かつ広範に蔓延するウイルスの媒体の役割を果たす。“Ｉ  ｌｏｖｅ  ｙｏｕ”のようなウイルスは大量増殖のために分散サービス妨害（ＤＤｏＳ）のアタッカーによって開発された技術を利用している。“Ｉ  ｌｏｖｅ  ｙｏｕ”ウイルスを受信すると、受信者のマイクロソフト・アウトルックはウイルスに感染されたｅ−メールをアウトルックのアドレス帳にある全員に送信する。“Ｉ  ｌｏｖｅ  ｙｏｕ”ウイルスはそれが放出されたから短期間で１００万台ものコンピュータを感染させた。コード・レッドのようなトロイの木馬はそれを蔓延させるために上記と同じ技術を利用している。ウイルスおよびトロイが原因で、ダウンタイムおよび極めて重要なデータの損失により生産性が大幅に低下することがある。
【００２５】
ニムダ・ウオームはｅ−メールとウエブ・アプリケーションの双方を同時に攻撃する。これは感染したｅ−メール・メッセージを作成、送信することによって自己増殖し、ネットワークを介してコンピュータを感染させ、ウエブ・メールを提供するために交換メール・サーバー上で展開されている無防備なマイクロソフトＩＩＳＷｅｂサーバーを攻撃する。
【００２６】
ほとんどのｅ−メールおよびＷｅｂ要求および応答は現在ではプレーン・テキストで送信され、ポストカードのように露出されている。それにはｅ−メール・メッセージ、そのヘッダ、および添付メールが含まれ、またはＷｅｂのコンテキストではユーザー名およびパスワードおよび／またはＨＴＴＰ要求におけるクッキー情報が含まれる。加えて、ｅ−メール・メッセージを送信または受信するためにインターネット・サービスプロバイダ（ＩＳＰ）にダイアルすると、ユーザーＩＤおよびパスワードもプレーン・テキストで送信され、これはスヌープ（監視）され、コピーされ、改ざんされる可能性がある。これは痕跡を残さずに実行可能であり、メッセージが損なわれたかを知ることが不可能になる。
【００２７】
インターネットは一層広範に利用されるようになってきたので、ユーザーにとっても新たなトラブルが生じるようになった。具体的には、個々のユーザーが受信した“スパム”（迷惑メール）の量は最近になって激烈に増加してきた。本明細書で用いるスパムとは、受信者が頼んでも望んでもいない何らかの通信の受信のことである。
【００２８】
下記はインターネット・アプリケーションによって誘発されるその他のセキュリティ・リスクである。
【００２９】
・ｅ−メールスパミングが企業資源を消耗刺せ、生産性に打撃を与える。その上、スパム送信者は無認可のｅ−メール中継用に企業独自のメール・サーバーを利用し、そのメッセージがあたかもその企業から着信したように見せかける。
【００３０】
・不適切なメッセージおよびＷｅｂページの送信および受信のようなｅ−メールおよびＷｅｂの悪用は企業にとってマイナス材料を生ずる。企業は従業員が送信または受信したｅ−メールによるセクシャルハラスメントまたは誹謗中傷の訴訟に直面することが増えている。
【００３１】
・医療保険の携行性と責任に関する法律（ＨＩＰＰＡＡ）、および金融制度改革法（金融機関を規制）のような法規の基準が、ｅ−メール、Ｗｅｂページ、およびＨＴＴＰ要求を含むｅ−メールおよび／またはＷｅｂサーバーまたは通信に機密の患者またはクライアント情報が曝されることがある企業にとってマイナス材料を生ずる。
【００３２】
“常開”ポートを利用して、ハッカーは適当なインターネット・アプリケーション・サーバーに簡単に到達し、その無防備さを食い物にし、サーバーを乗っ取る。それによってハッカーは、攻撃を受け易い機密情報を含むことが多い、サーバーが利用できる情報に容易にアクセスできる。本発明によるシステムおよび方法は、“常開”接続を必要とするこのようなインターネット・アプリケーションに含まれる通信に対して強化されたセキュリティを提供するものである。
【００３３】
今日利用されているアンチスパム・システムには着信メッセージが全てスパムを排除するためにフィルタにかけられるフェール・オープン・システムが含まれる。これらのシステムでは、メッセージはある形式の試験がそうであることを実証するまではスパムではないものと見なされる。メッセージは識別技術に基づいてスパムであると判定される。このようなシステムのオペレータは誤ってスパムであると分類される適正なメッセージの数を減らすための努力に相当のリソースを投資し続ける。分類ミスの不利益は相当なものであるため、ほとんどのシステムはメッセージをスパムであると分類しにくいように設計されている。
【００３４】
このようなアプローチの１つはｅ−メールを求めているユーザーをリストに明示することをユーザーに対して要求する。このようなリストはある種の“ホワイトリスト”である。このようなホワイトリストを作成するには現在２つのアプローチがある。デスクトップ環境では、最終ユーザーはアドレス帳をホワイトリストとしてインポートすることができる。このアプローチは、組織のゲートウエイのようなより中央のロケーションで動作される場合には重荷になることがある。したがって、組織によっては必要に応じてわずかなエントリしかホワイトリストには追加しないものもある。しかし、この場合はホワイトリスト作成の完全な効果は達成されない。本発明は、最終ユーザーまたは管理者による手動的な努力への要求を少なくしつつ、ホワイトリスト作成のより効率的な解決方法を可能にするシステムを含めることによって、上記のシステムを改良するものである。本発明によってさらに、送信者情報を認証することによってホワイトリスト・システムを強化することが可能になる。
【００３５】
今日利用されている別のシステムは、送信者が適法性を証明しなければならないフェール・クローズド・システムである。この種類のシステムの一般的な例は、チャレンジ−レスポンスを利用している。このようなシステムは未知の送信者からのメッセージは全て遮断し、それ自体が送信者に確認メッセージを送信する。送信者はこれに応答してそれが適正な送信者であることを立証しなければならない。送信者が応答すると、その送信者はホワイトリストに加えられる。しかし、スパム送信者は確認メッセージに応答するツールを作成することができる。ある種の確認メッセージは、人が応答を送信することを要求する努力においてさらに進歩している。本発明はこれらのシステムを改良する。本発明は送信者の確認に依存するのではなく、誰がホワイトリストに加えられるべきかを判断するためにユーザーによって提供された情報を参照することができる。本発明によるシステムおよび装置は電子通信の自動処理の精度を強化する。
【００３６】
開示内容が参照によって本発明に組み込まれている、ブライトライトテクノロジー社に授与された米国特許明細書第６，０５２，７０９号は、ルールを作成し、サーバーに送信することが可能であるようにスパム・メッセージを収集するシステムを開示している。開示されているシステムはデータ収集工程と、ルール作成工程と、クライアントにルールを配信する工程とを含んでいる。開示されたシステムはスパム・メッセージ用の特定のデータ収集方法に対するものである。入力されたデータに基づいてルールを作成するシステムまたは方法は開示されていない。これはさらに、ルールを作成する体系的なアプローチも開示していない。その上、開示されているシステムはスパムの脅威に限定されており、１種類の入力しか許容しない。本発明の脅威管理センターは、それらに限定されるものではないがスパム、ウイルス、ウォーム、トロイ、侵入の企てなどを含むあらゆるメッセージへの脅威に対して動作する。本発明の脅威管理センターはさらに、ルール作成プロセスへの新規のアプローチも含んでいる。加えて、本発明はさらに汎用で有用なデータ収集のアプローチを提供することによって先行技術を改良する。本発明のデータ収集システムにはルール作成プロセスが利用できるデータへの入力を処理するモジュールを含んでいる。本発明はさらに、ルール作成プロセスへの入力として、アプリケーション層セキュリティ・サーバーからのフィードバックを利用することもできる。
【００３７】
開示内容が参照によって本発明に組み込まれている米国特許出願第１０／１５４，１３７号（公刊番号２００２／０１９９０９５号）は、メッセージ・フィルタリングのためのシステムを開示している。開示されているシステムによって、スパム・メッセージはシステムのユーザーによってデータベースへと送出されることができる。これに対して、本発明のシステムおよび方法はユーザーに依存せず、むしろメッセージ送信セキュリティ・システム（単数または複数）が識別技術を利用して自動的にスパムを判定し、その後、結果をデータベースに送出することができる。本発明のシステムはシステムを保持するために、判明しているスパム・メッセージ、ならびにユーザーによって送出された分類ミスのメッセージをデータベースに加えることができる。公知のシステムではメッセージ全体をデータベースに送出する必要がある。本発明では、個々のメッセージ、またはアプリケーション層セキュリティ・システムはスパン・メッセージ、脅威メッセージ、および／または非スパム／非脅威メッセージから有意の特徴を抽出し、関連する特徴だけをデータベースに送ることができる。
【００３８】
開示内容が参照本によって本明細書に組み込まれている米国特許第６，１６１，１３０号は“ジャンク（迷惑）”ｅ−メールを検出する技術を開示している。開示されているシステムはスパムに対してのみ動作し、全種類のメッセージ・セキュリティへの脅威に対しては動作しない。開示されているシステムのための入力は限定されたスパムおよび非スパムｅ−メールである。この特許はメッセージ中のトークンのようなテキスト分析をベースにした機能を開示している。この特許は“あらかじめ規定された手作りの区別”を開示しているが、それらが何であり、どのようにして作成できるかは開示していない。本発明のシステムはテキスト分析だけではなくメッセージの他の特徴に基づく分類も可能である。加えて、本発明のシステムはヘキスト・ベースではない特徴を抽出するための全自動機能を含むことができる。
【００３９】
さらに、脅威情報のピア・ツー・ピア・システムを提供するための公知のセキュリティ・システムが開発されている。このようなシステムは典型的には信頼できないピアのリング向けに開発されたものなので、ピア間の信用管理に対処するものである。さらに、現在のピア・ツー・ピア・システムは中央エンティティを有していない。本発明のシステムは信頼されているピアの集合間で動作する。したがって、本発明は信用管理を取り扱う必要はない。さらに、集中化された脅威管理システムは、ピア・ツー・ピア式に通信する複数の信頼できるアプリケーション層セキュリティ・システム間で脅威情報をコーディネートする。したがって、脅威通知システムはよりリアルタイムのデータ交換を処理することができる。それによって分散ＩＤＳ（侵入検出システム）をよりスケーラブルにできる。
【００４０】
さらに、現行のシステムは侵入警報しか交換しない。これらのシステムはこれらが把握している攻撃を互いに通知できるだけである。根底にある検出システムは誤用または異常の検出が可能であるものの、交換されるデータは検出された攻撃データだけである。本発明のシステムはトラフィック・パターン、ならびに特定の脅威情報に関するより包括的な情報を配信する。限定するものではないが一例として、異常の検出が利用された場合、本発明のシステムは攻撃があることを示すため、統計を待つのではなく、基礎をなす統計を交換することができる。高官される統計にはある攻撃の周波数に関する情報を含めることができる。したがって、他のシステムがある種の攻撃の形跡を既に有している場合でも、本発明のシステムはそれらのシステムにその攻撃の発生を通知する。さらに、ピア間でトラフィック・パターンを交換可能であり、その情報はトラフィック・パターンのグローバルな視野を推測するために他のピアによってさらに処理されることができる。この情報交換は各ノードがネットワーク・トポロジーのグローバルな視野を推測できるルーティング・プロトコルと同類であってよい。
【発明の開示】
【課題を解決するための手段】
【００４１】
(発明の要旨)
本発明は電子通信のセキュリティ配信のシステムおよび方法に対するものである。典型的なアーキテクチャは下記の構成要素の１つ以上を含むことができる。１）脅威情報を収集し、メッセージング・セキュリティ・システム用のルールおよび／または方針を作成することができる集中脅威管理センター、２）メッセージング・セキュリティ・システム間で動作可能なピア・ツー・ピアベースのメッセージング通知システム、および３）ソースへと向かう経路上でシステムに通知を送信することによって、ソースのできるだけ近くで通信を遮断する階層的メッセージング・プッシュバック・システム。
【００４２】
セキュア電子通信配信システム、またはセキュア配信を含む多様な機能をサポートする全体的な環境としての本発明の好適な実施形態は、システム・データ・ストア（ＳＤＳ）と、システム・プロセッサおよび電子通信がそれを介して送受信される１つ以上の通信ネットワークへの１つ以上のインターフェースとを含んでいる。ＳＤＳは所望のシステム機能を提供するために必要なデータを記憶し、これには例えば、受信した通信、このような通信に関連するデータ、判明しているセキュリティ・リスクに関する情報、セキュア配信機構に関する構成データ、受信者セキュア配信基本設定（ｐｒｅｆｅｒｅｎｃｅｓ）、１つ以上のアプリケーション用の通信に対する企業の方針（例えば企業のｅ−メール方針、Ｗｅｂアクセスのガイドライン、メッセージ質問パラメータ、およびホワイトリスト）に関する情報、および特定のセキュリティ・リスク、状況、または異常性の識別に対する所定の応答が含まれていてもよい。
【００４３】
ＳＤＳは多様な種類の情報を記憶するための複数の物理的および／または論理的データ・ストアを含んでいてもよい。データ記憶および検索機能はシステム・プロセッサまたはデータ・ストアに関連するデータ記憶プロセッサのいずれかによって提供されればよい。システム・プロセッサはいずれかの適宜の通信チャネル（単数または複数）を介してＳＤＳと通信する。システム・プロセッサは同一の、または異なる通信チャネル（単数または複数）を介して１つ以上のインターフェースと通信する。システム・プロセッサは電子通信の受信、送信、質問、分析および／またはその他の機能性を提供する１つ以上の処理要素を含んでいてもよい。
【００４４】
脅威管理センターでは、ＳＤＳはさらに１組以上の脅威管理目標、および／または１組以上のテスト・データを含んでいてもよい。したがって、好適な１つの脅威管理方法は、ある実施形態では上記に概説し、以下により詳細に記載する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。脅威情報は１つ以上のソースから受信される。このようなソースは外部セキュリティ・データベース、および１つ以上のアプリケーションおよび／またはネットワーク層セキュリティ・システムからの脅威情報を含むことができる。受信された脅威情報は正規の形式へと還元される。還元された脅威情報から特徴が抽出される。これらの特徴は目標のような構成データと組み合わせてルールを作成するために利用される。ある実施形態では、これらのルールは１組以上のテスト・データに対してテストされ、同一の、または異なる目標と比較される。１つ以上のテストで不合格の場合は、許容される誤差範囲内でテストに合格するまでルールが改良される。次にルールは１つ以上のアプリケーション層セキュリティ・システムに伝播される。
【００４５】
１つの好適な脅威プッシュバック方法は、ある実施形態では、上記に概説し、以下により詳細に説明する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。通信が受信される。受信された通信に関連する脅威のプリファイルが作成される。ある場合には、この作成は受信された通信に１つ以上のテストを実施することによって行われ、１つ以上のテストは各々、受信された通信を特定のセキュリティ・リスクに関して評価する。別の場合は、備えられたインターフェースを介した脅威プロファイルの手動入力が脅威プロファイルを作成する役割を果たす。脅威プロファイルは構成情報と比較される。標準的には、構成情報は対象となる脅威の種類、およびこれに関連する重みを含むことができる。ある実施形態では、脅威プロファイルから脅威の数値を計算し、その脅威値が所定の脅威条件を満たすか否かを判定することによって比較が行われる。比較の結果、受信された通信が脅威を表すことが示されると、受信された通信のバックパス内の１つ以上のアドレスが識別され、記憶された脅威プロファイルに基づく情報が出力される。
【００４６】
ある実施形態では、バックパスに沿った識別された情報は脅威情報が伝播される前に認証される。別の実施形態では、１種類以上の脅威に関する構成情報を構築できるようにインターフェースを備えてもよく、構成情報は対象となる脅威の種類と、これに関する重みとを含んでいる。
【００４７】
したがって、ホワイトリストを利用する好適な方法の１つは、ある実施形態では、上記に概説し、以下により詳細に説明する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。ある実施形態では、アプリケーション・サーバーに向けられ、またはそこから発される電子通信が受信される。電子通信のソースは適宜の任意の内部または外部クライアントでもよく、または適宜の任意の内部または外部アプリケーション・サーバーでもよい。受信された通信を特定のセキュリティ・リスクに関して評価するため、受信された電子通信に対して１つ以上のテストが実施される。このテストに基づいて、受信された電子通信に関連するリスク・プロファイルが記憶される。記憶されたリスク・プロファイルは以前に受信された電子通信から累積されたデータと比較されて、受信された電子通信が異常であるか否かが判定される。受信された電子通信が異常であると判定され場合は、異常表示信号が出力される。出力された異常表示信号は、ある実施形態では、適宜の通知機構（例えば書面、ｅ−メールなど）によってアプリケーション・サーバーの管理者に対して検出された異常を通知してもよく、またはアプリケーション・サーバーの全面的な、または部分的なシャットダウンのようなある種の修正手段をトリガしてもよい（例えば、特定のソースからの全て通信へのアクセスの拒絶）。
【００４８】
ある実施形態は、記憶されたリスク・プリファイルに基づいて通信情報のためのサポートを、さらに別のセキュリティ装置（単数または複数）に対する脅威通知システムに提供できる。限定されるものではないが、このようなセキュリティ装置には脅威管理センター、およびその他のアプリケーション層セキュリティ・システムを含めることができる。このような情報の通信はいずれかの異常表示信号の代用になり、またはそれに加えることができる。ある実施形態では、異常の検出が行われる必要もなく、異常表示信号が出力される必要もない。
【００４９】
ある実施形態では、ｅ−メール・サーバーに向けられ、またはそこから発される電子通信が受信される。受信された電子通信の送信者アドレスと、１つ以上のホワイトリストに含まれるアドレスとを比較するため、受信された電子通信に１つ以上のテストが実施される。
【００５０】
ある実施形態はさらに、受信された電子通信をテストする特定のアプローチをサポートすることもでき、これはネットワーク・レベルのセキュリティおよび侵入の検出に適用してもよい。このような実施形態では、受信された各通信は複数個の質問エンジンによって質問され、このような各々の質問エンジンは特定のセキュリティ・リスク向けに通信をテストするように設計された特殊な種類のエンジンである。受信された各通信は異なる種類の一連の質問エンジンによって質問される。受信された通信で利用される質問エンジンの種類の順番と選択は、ある実施形態では構成可能であるが、別の実施形態では順番と選択が固定されることもある。
【００５１】
各質問エンジンには、特定の質問エンジンによって評価される通信向けのインデックス待ち行列（ｑｕｅｕｅ  ｏｆ  ｉｎｄｉｃｅｓ）が関連している。通信が受信されると、これは記憶され、インデックスが割り当てられる。受信された通信用のインデックスは、質問エンジンの順番によって決定される特定の種類の質問に関連する待ち行列内に配置されている。割り当てられた待ち行列に関連する質問エンジンによる受信された通信の査定が完了すると、質問エンジンの順番によって決定される次の種類の質問エンジンに関連する新たな待ち行列内にインデックスが割り当てられる。割り当て工程は、受信された通信が質問エンジンの選択によって決定された各種の質問エンジンによって査定され終わるまで継続される。その通信が各種の質問エンジンを首尾よくパスすると、通信は適宜の宛先に送出される。ある実施形態では、通信がいずれかの特定のエンジンをパスしないと、警告表示信号が出力されてもよい。このような実施形態の中には、次に通信が不合格の表示尽き、または表示なしで適宜の宛先、アプリケーション管理者および／または双方に送出される実施形態もある。
【００５２】
ある実施形態では、システムはメッセージを宛先に送出するために選択されたセキュア配信機構を利用することができる。このようなセキュア配信は、上記、または下記の質問および／または脅威管理機能のどれをも必要としない独立した自立型システムとして行われることができ、または上記の機能の一部または全部を供給する統合された環境で動作してもよい。
【００５３】
本発明は通信リンクにセキュリティをかけることによって（チャネル層セキュリティ）、または送信データにセキュリティをかけることによって（メッセージ層セキュリティ）セキュア通信サービスを提供することができる。チャネル層セキュリティおよびメッセージ層セキュリティは別個に、または組み合わせて提供されることができる。本発明の幾つかの好適な実施形態は、ＳＳＬまたはＴＬＳを利用してチャネル層セキュリティを提供することができる。本発明の好適な一実施形態は、限定的ではない例として、例えばｅ−メールおよびＷｅｂ要求および応答を含む電子通信を送信および／または受信することが可能である。これに加えて、またその代替として、本発明は適用可能なプロトコルを利用したインスタント・メッセージ、ファイル、ページャ・メッセージおよび音声のような別の形態の電子通信を送信および／または受信することが可能である。
【００５４】
したがって、セキュア配信の１つの好適な方法は、ある実施形態では上記に概説し、以下により詳細に記載する環境によって実行され、またはコンピュータ読み出し可能媒体の適宜の任意の組み合わせ内の、および／または組み合わせ上のコンピュータによる実行可能な命令として記憶されることができる多様な工程を含んでいる。ある実施形態では、受信された通信がセキュア配信を要求しているか否かの判定がなされる。このような実施形態のあるものでは、構成されたデフォールトがセキュア配信を要求することがある。別の実施形態では、セキュア配信が想定されているか否かの判定をする必要がない。所定の受信者への通信のセキュア配信が試行される。この試行は利用可能な１つ以上の配信機構群から選択されたセキュア配信機構を利用する。ある実施形態では、最初の試行が失敗すると第二の配信機構が選択され、この第二の機構を介した配信の試みがなされる。このような実施形態のあるものでは、配信が成功するまで、またはるよう可能な機構が使い果たされるまで別の機構によって配信する反復的な試行がなされてもよい。
【００５５】
この待ち行列アプローチを利用したある実施形態では、受信された通信用のインデックスの、特定の種類の質問エンジン用の待ち行列への割り当てには、特定の種類の質問エンジン用の全ての待ち行列への電流負荷の評価が含まれてもよい。閾値の負荷が存在する場合、特定の種類の質問エンジンの新たなインスタンスが、関連するインデックス待ち行列と共に発生することがある。その場合は、受信された通信用のインデックスが前記の質問エンジン・インスタンスに関連する待ち行列に割り当てられてもよい。ある実施形態では、特定の種類の質問エンジンに関連する待ち行列にかかる負荷は、新たに受信された通信に関連するインデックスを待ち行列へと割り当てる前に、新たな質問エンジン・インスタンスに関連する待ち行列を含む待ち行列全体に再分散されてもよい。ある実施形態はさらに、周期的に、または特定の待ち行列が空であると判定された場合のような特定の時点である種の質問エンジン用の待ち行列への負荷を評価し、動作停止閾値になると、その種類の過度の質問インスタンスをシャットダウンし、シャットダウンされたインスタンスに関連するインデックス待ち行列を引き離し、または割り当てを解除（ｄｅａｌｌｏｃａｔｉｎｇ）する。
【００５６】
あるいは、各々の特定種類の固定数の質問エンジンを構成してもよく、その場合はダイナミック・インスタンス生成が生じても生じなくてもよい。ダイナミック・インスタンス生成をサポートしない固定インスタンスの実施形態では、所望の特定の種類の各質問エンジン・インスタンスに関連する待ち行列の負荷の評価、または連続循環を含む任意の適宜のアプローチによって特定の待ち行列への割り当てがなされてもよい。
【００５７】
ある実施形態では、異常の検出は下記のように略述される工程を経て行われてもよい。このような工程では、受信された通信に関連するデータが収集される。データは多様なソース、例えば通信自体から、および通信の送受信の態様から収集できる。データは上記に概説し、以下に詳述する多重の待ち行列質問のような任意の適宜の態様で収集してよい。あるいはデータ収集は、多様なテストが受信された通信に個別的に並行して実施される並行テスト工程から行われてもよい。別の実施形態では、多次元にわたる受信された通信に関連するデータを同時に収集するため、例えばニューロネットワークを介した単一の複合的分析を適用してもよい。
【００５８】
収集されたデータは次に、受信された通信が異常を呈しているか否かを判定するために分析される。この分析は典型的には、以前に受信された通信に関連する集計されたデータによって表される所定期間を経て確立された通信パターンと共に、受信された通信に関連する収集済みデータに基づいて行われる。分析はさらに、規定された、および／または構成可能な異常ルールに基づくものでもよい。ある実施形態では、分析をデータ収集と組み合わせてもよい。例えば、ニューロネットワークが、受信された通信に関連するデータを収集し、これを分析する双方を行うことができよう。
【００５９】
適応通信質問は以前に受信された通信に関連する統合されたデータによって表される、構築された通信パターンを所定期間利用することができる。分析はさらに、規定されたおよび／または構成可能なスパム・ルールに基づいて行うことができる。ある実施形態では、分析をデータ収集と組み合わせることができる。例えば、ニューロ・ネットワークは受信された通信に関連するデータの収集とその分析の双方が可能であろう。
【００６０】
最後に、受信された通信に関して異常が検出されると、表示信号が発生される。発生された信号はアプリケーションの管理者に警告を発してもよく、他の何らかの適切な動作を起動してもよい。ある実施形態では、発生された表示信号は異常の一般化された表示を行ってもよい。別の実施形態では、表示信号は検出された特定の異常（単数または複数）に関する追加データを供給してもよい。後者の実施形態では、信号に起因するどの警告および／またはアクションも追加データに依存することができる。
【００６１】
この実施形態では、受信された通信が１つ以上のホワイトリストにあるか否かを判定するため、信号に誘発されるいずれかの警告および／または動作を分析することができる。分析は典型的には、１つ以上のホワイトリストの参照と共に、受信された通信に関連する収集済みデータに基づいて行われる。ホワイトリストとの一致が見出されない場合は、通信にはあるレベルの質問を受けることができる。ホワイトリストとの一致が見られた場合は、通信はメッセージ質問を迂回するか、別のレベルの質問を受けることができる。好適な一実施形態では、ホワイトリストとの一致が見られた場合は、通信は適応メッセージ質問を受けるか、またはメッセージな質問を受けないことができる。ホワイトリストとの一致が見出されない場合は、メッセージは通常のメッセージ質問を受けることができる。さらに、アウトバウンド通信に基づいてホワイトリストを作成および／または更新することができる。好適な一実施形態では、アウトバウンド通信の宛先アドレスの一部または全部がホワイトリストに加えられる。宛先アドレスが既にホワイトリストにある場合は、宛先アドレスの存在に基づいて、そのあて先に関連する機密値を修正することができる。例えば、利用カウントを保存してもよい。このような利用カウントは絶対的なアドレス利用回数、または所定の期間にわたるアドレス利用回数を反映することができる。
【００６２】
本発明のその他の利点は、一部は以下の説明で開示され、また一部は説明か羅明らかになり、または本発明の実施によって学習できよう。本発明の利点は添付の特許請求の範囲で特に指摘した要素および組み合わせによって実現され、獲得される。これまでの一般的な説明と以下の詳細な説明は例示および説明目的であるに過ぎず、特許請求がなされている本発明を限定するものではないことを理解されたい。
【００６３】
（発明の詳細な説明）
ここで本発明の実施例を詳細に説明する。図を参照すると、図面全体を通して同様の番号は同様の部品を示す。本明細書、およびそれに続く特許請求の範囲を通して用いられる“ａ”、“ａｎ”、および“ｔｈｅ”は文脈上で明らかに別の指図がない限りは複数指示を含む。さらに、本明細書、およびそれに続く特許請求の範囲を通して用いられる“ｉｎ”（中）は文脈上で明らかに別の指図がない限りは“ｉｎ”（中）および“ｏｎ”（上）の意味を含む。最後に、本明細書、およびそれに続く特許請求の範囲を通して用いられる“ａｎｄ（および）”および“ｏｒ（または）”は接続語と離切語の双方を含み、文脈上で明らかに別の指図がない限りは互換的に用いてもよい。
【００６４】
本明細書では範囲は１つの“およその”特定値から、および／または別の“およその”特定値までとして表されてもよい。このような範囲が表現された場合、他の実施形態は１つの特定値からおよび／または別の特定値までを含む。同様に、数値が“約”の先行詞を付して近似値として表される場合は、特定の値が別の実施形態を形成することが理解されよう。さらに、各々の範囲の端点は他の端点との関係で、および他の端点とは関わりなく、双方とも重要であることが理解されよう。
典型的なアクセス環境のアーキテクチャ
図１２は本発明の脅威管理アーキテクチャの様々な態様を利用した１つの環境を通る情報の流れの概観である。メッセージ・セキュリティ・システム（ＭＳＳ）（例えば１２０５）で、トラフィックおよび脅威パターンに基づいて統計が収集される。統計は個々のＭＳＳによってローカルに処理されることができ、または外部プロセッサによって処理されることができる。ＭＳＳはハードウエア・デバイス２１０のようなアプリケーション層セキュリティ・システムの例である。詳細な情報を１つ以上のＭＳＳから脅威管理センター（ＴＭＣ）１２１０へと返信可能である。ある実施形態では、複数個のＭＳＳがピア・ツー・ピア・システム１２１５として動作できる。好適な実施形態では、収集された情報および／または計算された統計をＭＳＳ１２０５から脅威通知およびプッシュバック・システム１２２０へと送信可能である。
アプリケーション層セキュリティ・システム
図１５は本明細書で詳細に後述するメッセージ質問エンジン（ＭＩＥ）の例４０３５を通るメッセージの流れを示している。ＭＩＥは質問するためのルールおよび方針を用いることができる。ＴＭＣからの入力はルールおよび１組のルールと方針４００５に加えることができる。ＭＩＥはレコードされた履歴に基づいて１組の統計４０１０を作成する。統計処理モジュール（ＳＰＭ）４０２５はこの情報を処理し、それを配信用に準備することができる。ある情報は分析４０３０のためにＴＭＣに返送可能である。情報はピア・ベースの脅威通知システムの一部としてピア４０１５に、またそこから送信可能である。情報はさらに、脅威プッシュバック・システム４０２０を利用してソースの方向に押し戻すことができる。ＳＰＭ４０１０はさらに、ピア・ベースの脅威通知システムおよび脅威プッシュバック・システムからの入力も受信できる。ＳＰＭ４０１０はその履歴と分析とに基づいて、ローカルＭＩＥ用の新たなルールおよび方針４００５を作成することができる。
【００６５】
図２は本発明による典型的な環境を示している。図１と比較して、本発明によるシステムおよび方法を利用したアクセス環境は、イーサーネット１８０のようなローカル通信ネットワークに接続され、ファイヤウォール・システム１４０とローカル・サーバー１２０とクライアント１３０との間に論理的に挿入されたハードウエア・デバイス２１０を含んでいてもよい。ファイヤウォール・システム１４０を経てローカル通信ネットワークに出入りしようとするあらゆるアプリケーション関連電子通信は、アプリケーション・レベルのセキュリティ査定および／または異常検出のためにハードウエア・デバイス２１０へと転送される。ハードウエア・デバイス２１０はローカル通信ネットワークを管理する既存のハードウエア素子から物理的に離される必要はない。例えば、本発明による方法およびシステムは標準型のファイヤウォール・システム１４０または同様の機能を有するルータ（図示せず）へと組み込むことができよう。ファイヤウォール・システムを利用しない環境では、ハードウエア・デバイス２１０が引き続きアプリケーション・レベル・セキュリティ査定および／または異常検出を行うことができる。
【００６６】
便宜上、および説明目的のみで、上記の説明ではハードウエア・デバイス２１０を参照している。しかし、本発明によるシステムおよび方法を実施するために使用されるハードウエアおよび／またはソフトウエアは、他の適宜のネットワーク管理ハードウエアおよびソフトウエア要素内にあってもよいことが当業者には理解されよう。さらに、ハードウエア・デバイス２１０は単一の素子として図示されている。ｅ−メールまたはＷｅｂのような特定の種類のアプリケーション・サーバー用のセキュリティを強化する複数のデバイスを使用してもよく、その場合は特定の種類の通信が例えば（１）通信を各デバイスに逐次割り当てる逐次割り当て、（２）現在のデバイスの負担に基づいて通信をデバイスに割り当てる、ハードウエアおよび／またはソフトウエア負荷平衡器の使用による割り当てのような適宜の割り当て戦略によって複数のデバイス間に割り当てられる。単一のデバイスが複数の種類のアプリケーション・サーバー全体に強化されたセキュリティを提供してもよく、または各デバイスが単一の種類のアプリケーション・サーバーだけに強化されたセキュリティを提供してもよい。
【００６７】
一実施形態では、ハードウエア・デバイス２１０は１Ｕまたは２Ｕサイズのラックマウント形のインテル・ベース・サーバーでよい。ハードウエア・デバイス２１０は利用可能性と拡張性を高めるために電源、プロセッサ、ディスクアレイのような冗長構成部品で構成されることができる。ハードウエア・デバイス２１０は暗号化されたメッセージの性能を増強するためにＳＳＬ／ＴＬＳアクセレータを含んでいてもよい。
【００６８】
ハードウエア・デバイス２１０は潜在的に複数の処理要素を含むシステム・プロセッサを含み、各処理要素は好適には少なくとも１つのＰＥＮＴＩＵＭ（登録商標）  ＩＩＩまたはＣＥＬＥＲＯＮ（インテル社、カリフォルニア州、サンタクララ）クラスのプロセッサによってサポートされてもよい。あるいは別の実施形態ではＵｌｔｒａＳＰＡＲＣ（サン・マイクロシステムカリフォルニア州パロアルト）を使用することができよう。ある実施形態では、以下にさらに記載するように、セキュリティ強化機能を複数の処理要素間に分散してもよい。処理要素という用語は（１）特定の部品で、または特定の複数の部品にわたって動作する処理、（２）特定のハードウエア部品、または文脈に沿う限り（１）または（２）のいずれかのことである。
【００６９】
ハードウエア・デバイス２１０は多様な一次または二次記憶素子を含むことがあるＳＤＳを有するであろう。好適な一実施形態では、ＳＤＳは一次記憶装置の一部としてＲＡＭを含むであろう。ＲＡＭの容量は１２８ＭＢから４ＭＢの範囲であろうが、これらの数量は可変的であり、本発明によるセキュリティ強化がファイヤウォール・システムに組み込まれる場合のように重複利用を表すことができよう。一次記憶装置はある実施形態ではキャッシュメモリ、レジスタ、不揮発性メモリ（例えばＦＬＡＳＨ、ＲＯＭ、ＥＰＲＯＭなど）などのような他の形式の記憶装置を含んでいてもよい。
【００７０】
ＳＤＳはさらに、単一、多重、および／または可変サーバーおよび記憶素子を含む二次記憶装置を含んでいてもよい。例えば、ＳＤＳはシステム・プロセッサに接続された内部記憶装置を使用してもよい。単一の処理要素はセキュリティ強化機能の全てをサポートする実施形態では、ローカル・ハードディスク・ドライブはＳＤＳの二次記憶装置として機能してもよく、このような単一の処理要素上で実行されるディスク・オペレーティングシステムはデータ・要求を受信し、サービスするデータ・サーバーとして機能してもよい。
【００７１】
本発明によるセキュリティ強化工程およびシステムで利用される異なる情報は、ＳＤＳ用の二次記憶装置として機能する単一のデバイス内で論理的、または物理的に下記のように区分されてもよいことが当業者には理解されよう。すなわち、共にＳＤＳとして機能する統一管理システムを介してアクセス可能な複数の関連データと、実施形態によっては全体としてＳＤＳと見なされてもよい異種の管理システムを介して個々にアクセス可能な複数の独立したデータ・ストアである。ＳＤＳの物理的構造を構成する多様な記憶素子は集中して配置してもよく、または多様な異なる位置にわたって分散されてもよい。
【００７２】
システム・データ・ストアの二次記憶装置のアーキテクチャは異なる実施形態では大幅に変化することがある。幾つかの実施形態では、データを記憶し、処理するためにデータベース（単数または複数）が使用される。このような実施形態のあるものでは、ＤＢ２（ＩＢＭ、ニューヨーク州ホワイトプレーン）、ＳＱＬサーバー（マイクロソフト、ワシントン州レッドモンド）、ＡＣＣＥＳＳ（マイクロソフト、ワシントン州レッドモンド）、ＯＲＡＣＬＥ８ｉ（オラクル社、カリフォルニア州レッドウッド  ショアー）、Ｉｎｇｒｅｓ（コンピュータ・アソシエーツ、ニューヨーク州アイランディア）、ＭｙＳＱＬ（ＭｙＳＱＬ  ＡＢ  スエーデン）、または適応サーバー・エンタープライス（Ｓｙｂａｓｅ  Ｉｎｃ．カリフォルニア州エミリービレ）のような１つ以上の関連データベース管理システムを、それに限定されるものではないがＩＤＥおよびＳＣＳＩを含む任意の適宜のインターフェースを使用した１つ以上の標準型の磁気および／または光ディスクを含んでいてもよい多様な記憶デバイス／ファイルと共に使用してもよい。ある実施形態では、Ｅｘａｂｙｔｅ  Ｘ８０（イグザバイト・コーポレーション、コロラド州ボールダー）のような、テープ・ライブラリ、ＥＭＣ  Ｉｎｃ．（マサチューセッツ州ホプキントン）から市販されているようなストレッジ・アタッチト・ネットワーク（ＳＡＮ）の解決手段、ＮｅｔＡｐｐフィルタ７４０（ネットワーク・アプリカンス、カリフォルニア州サンバレー）のようなネットワーク・アタッチト・ストレッジ（ＮＡＳ）の解決手段、またはそれらの組み合わせを使用してもよい。別の実施形態では、データ・ストアはオブジェクト指向、空間、オブジェクト関連、または階層的構造のような別のアーキテクチャのデータベースを使用してもよく、またはハッシュテーブルまたはフラット・ファイル、またはそのようなアーキテクチャの組み合わせを使用してもよい。このような代替アプローチは、ハッシュテーブル参照用サーバー、手順および／または工程、および／またはフラット・ファイル検索サーバー、手順および／または工程のようなデータベース管理システム以外のデータ・サーバーを使用してもよい。さらに、ＳＤＳはその二次記憶装置のアーキテクチャを組成する際に上記のアプローチのどの組み合わせをも利用できる。
【００７３】
ハードウエア・デバイス２１０はＷＩＮＤＯＷＳ（登録商標）／ＮＴ、ＷＩＮＤＯＷＳ（登録商標）２０００、またはＷＩＮＤＯＷＳ（登録商標）／ＸＰサーバー（マイクロソフト、ワシントン州レッドモンド）、Ｓｏｌａｒｉｓ（サン・マイクロシステムカリフォルニア州パロアルト）、またはＬＩＮＵＸ（またはその他のＵＮＩＸ（登録商標）のバリエーション）のような適宜のオペレーション・システムを有しているであろう。好適な一実施形態ではハードウエア・デバイス２１０は、ＦｒｅｅＢＳＤ（ＦｒｅｅＢＳＤ．Ｉｎｃ．，ｈｔｔｐ：／／ｗｗｗ．ｆｒｅｅｂｓｄ．ｏｒｇ）に基づく、事前にロードされ、事前に構成され、強化されたＵＮＩＸ（登録商標）オペレーティングシステムを含んでいる。この実施形態では、ＵＮＩＸ（登録商標）カーネルは大幅に縮減され、不可欠ではないユーザー・アカウント、不要なネットワーク・サービス、およびセキュリティ強化工程には必要ないいかなる機能をも除去している。オペレーティングシステム・コードはセキュリティの脆弱性をなくするように大幅に修正されている。
【００７４】
ハードウエア／オペレーティングシステム・プラットフォームに応じて、構成、監視および／または報告の目的の所望のアクセスをサポートするため、適宜のサーバー・ソフトウエアを含めてもよい。Ｗｅｂサーバーの機能はインターネット情報サーバー（マイクロソフト、ワシントン州レッドモンド）、アパッチＨＴＴＰサーバー（アパッチ・ソフトウエア・ファンデション、メリーランド州フォーレストヒル）、ｉＰｌａｎｅｔ  Ｗｅｂサーバー（ｉプラネットＥ−コマース・ソリュージョン−Ａ−Ｓｕｎ−ネットスケープ  アライアンス、カリフォルニア州マウンテンビュー）、またはその他の適宜のＷｅｂサーバー・プラットフォームを介して供給されることができる。ｅ−メール・サービスは交換サーバー（マイクロソフト、ワシントン州レッドモンド）、センドメールまたはその他の適宜のｅ−メール・サーバーによってサポートされることができる。ある実施形態は前述のアクセス・サーバーに加えて、または代替として１つ以上の自動音声応答（ＡＶＲ）システムを含んでいてもよい。このようなＡＶＲシステムは、（例えばプリンタ、ファクシミリなどのような）適宜のハードコピー出力デバイスに電子的に配信され、必要に応じて通常の郵便、宅急便（登録商標）、オフィス内メール、ファクシミリ、または他の適宜の送達アプローチを介して送られるハードコピー出力を伴う環境への純粋な音声／電話励起インターフェースをサポートできよう。好適な一実施形態では、アパッチ・サーバーのバリエーションがハードウエア・デバイス２１０を遠隔構成するためのインターフェースを提供する。構成、監視および／または報告はある形態の遠隔アクセス・デバイスまたはソフトウエアを利用して提供されることができる。好適な一実施形態では、ＳＮＭＰを利用してデバイスが構成および／または監視される。好適な一実施形態では、任意の適宜の遠隔クライアント・デバイスを利用してハードウエア・デバイス２１０へ、またそこから情報およびコマンドが送信され、検索される。このような遠隔クライアント・デバイスは従来のワークステーションまたは携帯用ワイヤレス・デバイスのような任意の適宜のプラットフォーム上で動作するＪａｖａ（登録商標）クライアントまたはウインドウズ・ベースのクライアントの形式で、またはこれも従来のワークステーションまたは携帯用ワイヤレス・デバイスを含む適宜のプラットフォームで動作する所有者クライアントの形式で提供されることができる。
アプリケーション層電子通信セキュリティ強化
図３は本発明によるセキュリティ強化システムの論理構成要素の構成図である。全般的な分析、報告、および監視機能はブロック３１０によって示され、異常検出はブロック３７０によって示されている。
【００７５】
ブロック３２０−３６０は電子通信になされる異なる査定を示している。これらのブロックは実行できる査定を示すものであり、可能なあらゆる種類のアプリケーション・サーバー用の可能なあらゆる査定を網羅した表示をなすものではない。“テスト”、および“テストする”という用語は本明細書、および下記の特許請求の範囲の記載で適当に“査定”または”査定する”と互換的に用いてもよい。
【００７６】
・アプリケーション特有のファイヤウォール３２０はアプリケーション特有の攻撃に対して防御する機能を果たす。例えばｅ−メールの文脈では、この査定は拡張ＳＭＴＰ、バッファのオーバーフロー、およびサービス拒否に向けられた攻撃に対して防御可能であろう。
【００７７】
・アプリケーション特有のＩＤＳ３３０はアプリケーション・サーバー特有の活動をリアルタイムで監視する。これはさらに、アプリケーション層、ネットワーク層、およびオペレーティング層を含む複数の層からの情報をも検索できる。これはアプリケーション特有のＩＤＳ監視の追加層を追加することによってネットワーク侵入検出システムを補う。
【００７８】
・アプリケーション特有のアンチウイルス防御およびアンチスパム防御３４０はアプリケーション特有の通信から関連するウイルスおよび／またはスパムを除去することをサポートする。
【００７９】
・方針管理３５０によって、アプリケーション特有のどの通信がいかにして送信され、コピーされ、またはブロックされるかに関する特定のアプリケーションに対する企業の方針を規定することが可能になる。しばしばウイルスおよび／またはウオームのソースとなる実行可能な添付または通信コンポーネントおよび／または疑念があるコンテンツはそれらがアプリケーション・サーバーまたはクライアントに到達する前に排除または、隔離されることができる。競合相手からのｅ−メールはブロック、またはコピーされることができる。言語メッセージはネットワークの輻輳を防止するためにピーク外時間に追いやる（ｒｅｌｅｇａｔｅ）ことができる。
【００８０】
・アプリケーション暗号化３６０はアプリケーション通信を確実に送受信し、ハードウエアの性能促進を潜在的に強化する。
【００８１】
アプリケーション・セキュリティ・システムは着信する通信を処理し、ネットワークの侵入者にとって実際のアプリケーション・サーバーであるように見える。それによって実際の企業アプリケーション・サーバーは直接、間接の攻撃が防止される。
【００８２】
ローカル通信ネットワークに出入りしようとする電子通信は査定のために本発明を通って転送されることができる。この査定の結果は、そのメッセージが対象となる受信者に配信されるか否かを決定することができる。
【００８３】
着信および送信通信、およびその添付メールは本発明によるセキュリティ・システムによって受信される。好適な一実施形態における通信はｅ−メール・メッセージである。別の実施形態での通信はＨＴＴＰ要求または応答、ＧＯＰＨＥＲ要求または応答、ＦＴＰコマンドまたは応答、テルネットまたはＷＡＩＳインタラクション、またはその他の適宜のインターネット・アプリケーション通信であってよい。
【００８４】
本発明によるホワイトリスト作成の自動化によって、システムはアウトバウンドのｅ−メール・トラフィックに基づいて１つ以上のホワイトリストを自動的に作成および／または保存することが可能になる。ある実施形態では、システムはアウトバウンドのおよび／またはインバウンドのｅ−メール・トラフィックを監視し、それによってホワイトリストに加えられる適正なｅ−メール・アドレスを判定することができる。ソフトウエアはどのアウトバウンド・アドレスが実際に適正なアドレスであるかを決定するために１組のメトリクスを利用できる。
【００８５】
受信された通信に１つ以上の査定戦略を適用するデータ収集工程が実施される。上記に概説出力、下記に詳細に説明する多重待ち行列質問アプローチは好適な一実施形態ではデータ収集機能を備えている。あるいは、査定は受信された各メッセージで並行して行われてもよい。システム・プロセッサの別個の処理要素は受信されたメッセージにそれぞれの査定を加える役割を担うであろう。一実施形態では、ニューラル・ネットワークのようなアプローチを利用して受信された通信で同時に複数のリスク査定を行うことができる。各査定、または査定全体の適用によって、受信された通信に関連する１つ以上のリスク・プロファイルが生成される。受信された通信の査定に基づいて作成されるリスク・プロファイルまたはログ／ファイルはＳＤＳ内に記憶される。収集されたデータは脅威の分析または鑑定を行うために利用できる。この工程は通信が既に受信され、送出された後で行ってもよい。
【００８６】
好適な一実施形態では、特定の査定がアプリケーション管理者によって構成可能にイネーブルまたはディスエーブルにされることができる。上記のように、アプリケーション管理者による構成を容易にするために適宜の構成インターフェース・システムを備えてもよい。
【００８７】
異常検出工程は、以前に受信された通信に関連するデータにかんがみて異常であるか否かを判定するために、受信された通信に関連する記憶されたリスク・プロファイルを分析する。好適な一実施形態では、上記に概説し、下記に詳述する異常検出工程がこの検出機能をサポートする。ある実施形態での異常検出は査定と同時に行ってもよい。例えば、複数のリスクに関して受信された通信を同時に査定するためのニューラル・ネットワークを利用した実施形態は、受信された通信の異常をさらに分析できる。このような実施形態では、以前に受信された通信に関連するデータはニューラル・ネットワーク内での重み係数としてエンコードされることができる。
【００８８】
ある実施形態では、様々な種類の異常性の閾値を以前受信された通信に関連するデータに基づいて動的に決定してもよい。あるいは、個々の種類の異常性に関する特定の閾値を構成できるようにアプリケーション管理者にインターフェースを備えてもよい。ある実施形態では、閾値はアプリケーション管理者によって特別に構成されない限り、動的に導出できる。
【００８９】
異常性は典型的には特定の期間に基づいて検出される。このような期間は特定の固定期間（例えば先月、昨日、去年、セキュリティ・デバイスの最後の再起動以来など）であってよく、全ての種類の異常に適用される。あるいは、アプリケーション管理者によって適宜のインターフェースを介してあらゆる種類の異常性、または各種の異常性ごとに個別にそれぞれの期間を構成することもできる。ある実施形態はあらゆる種類の異常性、または各種の異常性ごとに個別に固定期間のデフォールトをサポートしてもよく、これはアプリケーション管理者の構成によって無効にされることができる。
【００９０】
好適な一実施形態では、受信された通信に関連する記憶されたリスク・プロファイルは同じ種類の以前受信された通信に関連するデータと統合される。この新たな統合された１組のデータは次に、後に受信されるその種類の通信の分析に利用される。
【００９１】
異常が検出されると、異常表示信号が出力される。出力される信号は検出された異常と、異常が検出された通信とを特定するデータを含むことができる。ｅ−メール・アプリケーション・セキュリティに関する様々な種類の異常性を以下に記載する。これらの種類の異常性は以下に記載する特定の検出アプローチ、または前述のいずれかの異常検出の代替アプローチを利用して検出できる。
【００９２】
出力された信号はある実施形態ではさらに別の応答をトリガしてもよい。あるいは、出力された信号が応答であってもよい。好適な一実施形態では、出力された信号は１つ以上のそれぞれ特定された配信プラットフォームを介して１人以上の指定の受信者に対する通知であってよい。例えば、通知はｅ−メール・メッセージ、ページ、ファクシミリ、ＳＮＭＰ（簡易ネットワーク管理プロトコル）警報、ＳＭＳ（ショート・メッセージ・システム）メッセージ、ＷＡＰ（ワイヤレス・アプリケーション・プロトコル）警報、音声通話またはその他の適宜なメッセージで警告するＯＰＳＥＣ（オペレーション・セキュリティ）の形態のものでよい。あるいは、このような通知は出力された信号によってトリガされることもできよう。
【００９３】
ＳＮＭＰを利用すると、マネージャーおよびエージェントを利用してネットワーク・レベルのセキュリティとインターフェースすることが可能になる。一例として、特定のルータを通るトラフィックの流れの監視があげられよう。ＯＰＳＥＣは重要な情報を保護するための公式の工程および方法である。ＷＡＰはワイヤレス・デバイスを有するモバイルのユーザーが瞬時に情報およびサービスに容易にアクセスし、これとインタラクトする権限を与える公開のグローバルな規格である。その例には、異常が検出された場合にＷＡＰをサポートするワイヤレス・デバイスへとＷＡＰページをフォーマット化することがあげられよう。ＷＡＰページはＨＴＭＬの簡易バージョン（ｓｔｒｉｐｐｅｄ  ｄｏｗｎ  ｖｅｒｓｉｏｎ）であり、ディスプレーが小さいワイヤレス・ネットワークおよびデバイス用に最適化されている。ＳＭＳはＮｏｋｉａ８２６０電話のようなワイヤレス・デバイスに短いテキスト・メッセージを配信する伝送用にＳＭＴＰおよびＳＮＭＰを利用するワイヤレス技術である。ＳＭＳメッセージはユーザーに対して異常警報の侵入検出を警報するためにこれらのデバイスに送信可能であろう。
【００９４】
通知の代わりに、または通知に加えて、出力された信号によって１つ以上の修正手段がトリガ可能であろう。このような修正手段には受信された通信のソースからのそれ以上の通信の受信拒否、通信の隔離、アプリケーション・サーバーによって安全に処理されるようにするための通信のストリッピング、および／または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによってメッセージング可能なレベルまで抑制することを含めることができよう。
【００９５】
好適な一実施形態では、アプリケーション管理者が所望の応答を選択的に構成でき、構成されたこの応答を特定の種類の異常と関連付けることによって、その種類の異常が検出されると、構成された応答が行われるようにするインターフェースを備えてもよい。
【００９６】
最後に、受信された通信に関して異常が検出されると、その通信は対象となる宛先に送出されても、されなくてもよい。異常であると判定された通信が送出されるかされないかは、ある実施形態では、あらゆる種類の異常に対して構成可能である。あるいは、個々の種類の異常に関して異常な通信の送出を構成することもできよう。このような実施形態のあるものでは、特別に構成されない個々の種類の異常に関してデフォールト・フォワーディングの設定を利用できよう。
セキュア通信配信
本発明によって実施される通信サービスは１つのシステム・プロセッサ上で実行可能であり、または複数のシステム・プロセッサに分散されてもよい。本発明の全ての関連機能は１人以上の管理者によって構成されることができる。好適な一実施形態は管理者が認可およびユーザー／ドメイン管理および機能構成を行うためのインターフェースを含むことができる。ユーザー・パラメータおよび認可の管理用にユーザー管理インターフェースを備えることができる。本発明は、いずれかの機能がメニュー方式のシステムで構成するためのインターフェースを有することができるように、プログラムまたは適応化することが可能である。
【００９７】
図１６を参照した好適な一実施形態では、インバウンド通信の処理工程は所定の受信者５００５に配信するように指定された電子通信の受信で開始される。受信された通信は、必ずしもすべての実施形態で層である必要はないが、脅威および／または異常の検出に関連して上述し、また後述するテストおよび分析を受ける。受信された通信５０１０と共に使用されるセキュア配信機構が選択される。この機構は利用できる配信機構の優先順位付けに基づいて選択される。選択された機構５０１５にしたがってメッセージを配信することが試行される。この試行が成功した場合は５０２０、工程は完了する５０２５。ある実施形態では、配信の試行が失敗すると、選択および配信試行工程を付加的に選択された配信機構で繰り返すことができる。このような実施形態のあるものでは、繰り返しは通信の配信に成功するまで、または利用できる全ての配信機構が試行されるまで継続可能である。ある実施形態では、セキュア配信機構を利用できない場合、または利用できるすべてのセキュア配信機構が失敗した場合はインセキュア配信が実施される。
【００９８】
好適な一実施形態では、配信機構はベース機構および１つ以上のオプションを含むことができる。ベース機構は好適にはインスタント・メッセージイング、ＳＭＴＰ、ＨＴＴＰ、またはＦＴＰである。一般に使用されている他の配信機構も適宜に使用可能であることが当業者には理解されよう。配信機構はさらにセキュリティ・オプションを含むことができる。これらのオプションは好適にはＨＴＴＰ提示を伴うＳＭＴＰ通知、Ｓ／ＭＩＭＥ、ＰＧＰ、ＴＬＳ、ＳＳＬおよびこれらの組み合わせを含むことができる。しかし、当業者には公知の他のチャネルおよび／またはメッセージ・レベル・セキュリティ技術も利用可能であろう。配信機構は適宜のメッセージ・レベル暗号化技術、チャネル・レベル暗号化技術、または２つの組み合わせを利用することができる。ある実施形態では、利用可能な配信機構を通信ソース、所定の受信者、デフォールト構成、またはそれらの組み合わせに基づいて選択することができる。
【００９９】
セキュア配信機構を選択する際、選択工程は利用可能なセキュア配信機構の決定と、このような機構の優先順序付けとを含んでいてもよい。決定および優先順位付けは、ある実施形態では、デフォールト優先順序付けによって規定された順序での特定の配信機構の利用可能性を逐次チェックし、このような利用できる最初の機構を選択するデフォールト優先順序付けの場合のように、選択工程と同時に、またはその一部として行われることができる。図１７はこのような工程の１つを示している。
【０１００】
好適なある実施形態では、配信機構は各配信機構に関連する格付けに基づいて優先順序を決めることができる。配信機構の優先順序付けは受信者または通信ソースに基づいて検索可能である。加えて、ある実施形態では、複数の配信機構の優先順序を指定するためのインターフェースを通信ソースに備えることができる。次にその優先順序は備えられたインターフェースから検索できる。それに加えて、またはその代替として、受信者が配信機構のデフォールト優先順序を指定できるようにするインターフェースを受信者に供給することができる。この構成情報は供給されたインターフェースから受信され、その受信者への通信のセキュア配信のために利用される。
【０１０１】
好適な一実施形態では、各配信機構に格付けをすることができる。格付けは配信効率、配信コスト、配信のセキュリティ、およびそれらの組み合わせを含む様々な判断基準に基づいて行われることができる。
【０１０２】
その代替として、あるいはその代わりに、複数の配信機構の優先順序を指定するためのインターフェースを管理者に供給することができる。指定された優先順位情報は次に、供給されたインターフェースから受信可能である。管理者によって指定された構成は例えば、配信機構のデフォールト優先順序を指定するために利用できる。
【０１０３】
ある実施形態では、通信がセキュア配信を要求しているかの判定が行われる。セキュア配信の要求は通信ソース、通信コンテンツ、通信の受信者、構成データ、およびこれらのベースの組み合わせに基づいて多くの態様で判定される。通信のコンテンツはセキュア配信が所望されていることを示すインデックスについてパーズされることができる。受信された通信は次に、パージングに基づくセキュア配信の要求として特定されることができる。パージングは受信された通信に１つ以上のフィルタリング・ルールを適用することによって実施可能である。フィルタリング・ルールはコンテンツ、添付、ソース、受信者、または当業者が適切であると認識するその他のインデックスに基づくものでよい。ある実施形態では、パージングハ例えばＳＭＴＰｅ−メール・メッセージまたはＨＴＴＰ要求または応答のヘッダ部分のような通信のヘッダ部分に限定されてもよい。１つ以上の所定のキーワードが受信された通信またはそのヘッダからパーズされた場合は、受信された通信はセキュア配信を要求しているものと特定できる。その代わりに、またはそれに加えて、セキュア配信を決定するために通信のソースまたは受信者を利用することができる。例えば、特定の受信者への、または特定のソースからの全てのメッセージがセキュア配信を要求しているものとすることができよう。さらに、管理者によって、または通信ソースから提示された構成データがセキュア配信のための特定の通信を指定する役割を果たすことがかのうであろう。
【０１０４】
本発明は配信される通信用のメッセージ・レベルおよびチャネル・レベルのセキュリティのいずれかの組み合わせを利用し、または利用を試行するように構成可能である。受信者およびドメインはデータベース内で多様なセキュア配信機構と関連付けすることができる。配信機構は上述のように優先順序付けが可能である。順序付けされた優先順序は配信機構、配信機構のベース機構、配信機構のセキュリティ・オプション（単数または複数）、またはそれらの要因の組み合わせに基づいて利用できる。好適な一実施形態では、順序付けされた優先順序は下記のように最高から最低までの配信機構に関連するセキュリティ・オプションに基づいている。すなわち、Ｓ／ＭＩＭＥ、ＰＧＰ、パスワードおよびランダムＵＲＬ付きのＳＷＭ（セキュアＷｅｂメール）、ＴＬＳまたはＳＳＬ、ランダムＵＲＬ付きのＳＷＭである。別の優先順序を用いてもよいことが当業者には理解されよう。このような代わりの順序は上記にリストしてセキュア配信機構の全部または一部を含むことができ、または含まないこともある。
【０１０５】
好適な一実施形態では、図１７に示すように、ＰＧＰ、Ｓ／ＭＩＭＥ、ＴＬＳまたはＳＳＬ、（ユーザー認証付き、またはなしの）ＳＷＭのセキュリティ・オプションに基づくデフォールト優先順序付けが利用される。通信が受信される５１００。段階５１０５、５１１５、５１２５、および５１３５に示すように、セキュア配信機構の選択はセキュリティ・オプションの暗黙的デフォールト優先順序付けにしたがって行われる。利用可能なセキュア配信機構の決定は下記の選択で同時に行われる。
【０１０６】
【表１−１】
2005520230.tif 000003
【０１０７】
【表１−２】
2005520230.tif 000004
【０１０８】
ある実施形態では、段階５１５０で配信が失敗した場合はループバックを行うことが可能である。ループバックの結果、失敗した機構の後で次に利用できる機構に戻るであろう。例えば、ＰＧＰを利用できると判定されたが失敗した場合は、ループバックが段階５１１５で工程に再び入って、Ｓ／ＭＩＭＥの利用可能性が判定されよう。このような代替機構では、次の段階に進む決定は、特定のセキュリティ・オプションの利用可能性の代わりに、またはそれに加えて配信の成功または失敗に基づいて行われる。これに加えて、または代替実施形態では、インセキュア配信段階は完全に除去されるか、または段階５１０５へのループバックで代替され、利用可能なセキュア配信機構が見つかるまでそのチェックを継続することができる。加えて、ループが固定回数だけ、または固定期間だけ行われるように、このようなループバックに制約を加えることができよう。
【０１０９】
本発明は独立して、または上記の、および後述とは別のネットワーク管理方法およびシステムと共に動作することができる。本発明の下記の構成要素を本発明に組み込むことができる。一旦組み込まれると、これらは別個に、または組み合わせて構成可能である。
セキュアＷｅｂメール（ＳＷＭ）
ＳＷＭはオリジナル・メッセージにアクセスするためのセキュア・ウエブ・ページへのリンクで受信者に通知メッセージを送信する。提供されたリンクがたどられると、受信者のブラウザはオリジナル・メッセージを含むサーバーとのセキュア接続を確立することができる。その後、メッセージをセキュアに閲覧できる。ブラウザ接続を介したメッセージへのアクセスも適宜な認証手段によってセキュリティを保つことが可能である。限定的ではない例として、ユーザー・アクセスの認証はランダムＵＲＬ、ユーザーネーム／パスワードの組み合わせ、またはこれらの組み合わせに基づくものでよい。
【０１１０】
好適な一実施形態では、既読または未読のメッセージを保存するために、受信者用の管理インターフェースを供給することができる。限定的ではない例として、メッセージが一度閲覧されるとこれを削除するようにシステムを構成することができる。
【０１１１】
ＳＷＭによって配信されるメッセージの各受信者向けに、ランダム・ストリングを生成可能であり、これを用いてＵＲＬを作成可能である。例えばＵＲＬ  ｈｔｔｐ：／／ｂｏｘｎａｍｅ／ｍｓｇ．ｊｓｐ？ｒａｎ＝１２ｆｕｇｒ１９８０ｄｈ８９を利用できよう。本発明はＵＲＬを封入したｅ−メールを作成できる。このようなｅ−メールは、含まれているリンクでメッセージを検索可能であることを受信者に伝えるために利用できる。本発明のある実施形態はユーザーネーム／パスワードまたはセキュアＩＤ認証機構を利用して追加認証を供給することができる。本発明のある実施形態は、ブラウザ・リンクを含むメッセージを表示する前にユーザー認証を行うように構成することができる。
【０１１２】
ＳＷＭは１つ以上の処理要素上で実行可能である。これらの処理要素は本発明のシステム・プロセッサの一部であってもよく、またはこれらとシステム・プロセッサとの間の通信リンクを別個に備えることもできる。いずれの場合も、受信された通信は本発明のＳＤＳ、または別個に備えられた処理要素に関連するある記憶装置へとコピーされる。ある実施形態では、ＵＲＬを作成するために通信のコピーの位置を利用できる。しかし、別の実施形態はコピーの位置に関わりなくＵＲＬを作成できる。
【０１１３】
ＳＷＭはメッセージ・レベル暗号化（例えばＳ−ＨＴＴＰ、Ｓ／ＭＩＭＥ、ＰＧＰなど）および／またはチャネル・レベル暗号化（例えばＳＳＬまたはＴＬＳ）を利用した適宜の暗号化によって受信された通信をセキュアに提示する。好適な一実施形態では、ＳＳＬチャネル・レベル暗号化はセキュア提示を行うためのセキュリティ・オプションとしての役割を果たす。暗号化で使用される様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに利用できる。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼され、認証された）キー・サーバーからこのようなキーを取得できる。
サーバー・ベースのＰＧＰ
サーバー・ベースのＰＧＰを含む実施形態はサーバー・ベースのＰＧＰメッセージを送信および／または受信するようにプログラムされ、または適応化されることができる。サーバー・ベースのＰＧＰは信頼性、認証、およびメッセージの完全性の保証を得ることが望まれる環境で使用することができる。この機能はＰＧＰフリーウエア（マサチューセッツ技術研究所、マサチューセッツ州ケンブリッジ）のようなツールキットを使用して実装可能であり、またはネットワーク・アソシエーツ・テクノロジーＩｎｃ．（カリフォルニア州サンタクララ）から供給されている。
【０１１４】
好適な一実施形態はＰＧＰ／ＭＩＭＥフォーマットを使用してメッセージを送信および／または受信できるドメインおよび／またはユーザーを管理する構成インターフェースを含むことができる。この管理インターフェースはさらにドメインのための公開鍵管理機能をも提供できる。本発明はＰＧＰ／ＭＩＭＥメッセージ・レベルの暗号化が必要であると指定された受信者またはドメイン用に、オリジナル・メッセージからＰＧＰ／ＭＩＭＥメッセージを作成するように構成できる。暗号化に使用されるための様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに利用可能である。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼され、認証された）キー・サーバーからこのようなキーを取得することができる。
着信メッセージ
本発明の好適な一実施形態では、着信メッセージの受信者またはドメインがデータベース内でＰＧＰユーザー・リスト上の受信者またはドメインと一致できた場合は、対応する公開鍵を使用してメッセージを解読できる。送信者の認証を行うこともできる。
発信メッセージ
好適な一実施形態では、発信メッセージの受信者またはドメインをＰＧＰユーザー・リストに対してチェックすることができる。受信者または宛先ドメインがＰＧＰユーザー・リストに出現する受信者またはドメインと一致すると、ＰＧＰ／ＭＩＭＥフォーマットを用いて新規の通信を作成できる。新規の通信は．ｐｇｐ拡張、またはその他の適宜の命名規則を有するオリジナルのファイルネームを使用して作成できる。作成後、適宜のプロトコルに従った工程が暗号化された通信を配信することができる。
サーバー・ベースのＳ／ＭＩＭＥ（セキュア／多目的インターネット・メール拡張）
本発明のある好適な実施形態はサーバー・ベースのＳ／ＭＩＭＥメッセージを送受信する能力を含むことができる。Ｓ／ＭＩＭＥはプライバシー、完全性を増強し、認証を与えるために利用できる。本発明はＳ／ＭＩＭＥフォーマットを要求するように指定されたオリジナル・メッセージの受信者および／またはドメインからＳ／ＭＩＭＥメッセージを生成することができる。この機能は構成可能にターンオンまたはターンオフできる。
【０１１５】
サーバー・ベースのＳ／ＭＩＭＥの機能はＳ／ＭＩＭＥツールキットを使用して実現可能である。ある好適な実施形態はＳ／ＭＩＭＥフォーマットをしようしてメッセージを受信および／または送信できるドメインおよびユーザーを管理するための構成インターフェースを含むことができる。ドメインの公開鍵の管理用のインターフェースも備えることができる。暗号化に使用される様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに入手できる。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼できる認証された）キー・サーバーからこのような鍵を入手することができる。
着信メッセージ
着信メッセージはそれがＳ／ＭＩＭＥフォーマットのものであるか否かをチェック可能である。メッセージの受信者または宛先ドメインが多くのＳ／ＭＩＭＥユーザー・リストと一致すると、メッセージは対応する公開鍵を用いて解読される。送信者の認証も行うことができる。
発信メッセージ
発信メッセージの受信者はＳ／ＭＩＭＥユーザー・リストに対してチェック可能である。受信者または宛先ドメインがＳ／ＭＩＭＥの暗号化を要求またはサポートしている場合は、Ｓ／ＭＩＭＥフォーマットに基づいて新規のメッセージを作成可能である。新規のＳ／ＭＩＭＥメッセージは．ｓｍｉｍｅ拡張、またはその他の適宜の命名規則を有するオリジナルのファイルネームを使用して作成できる。そこで本発明はＳ／ＭＩＭＥメッセージを対象とされる受信者に配信することができる。
ＳＳＬ／ＴＳＬ
好適なある実施形態では、ＳＳＬ／ＴＬＳまたはその他の適宜のセキュア・チャネル・プロトコルを用いたセキュア通信チャネルを利用して配信されることができる。受信者または宛先ドメインがチャネル・レベルの暗号化を要求またはサポートしている場合は、このようなチャネルを利用してメッセージを配信可能である。暗号化で使用される様々な公開鍵および秘密鍵は本発明のＳＤＳ内でローカルに利用できる。それに加えて、またはその代わりに、システム・プロセッサは適宜の（好適には信頼され、認証された）キー・サーバーからこのようなキーを取得できる。
脅威管理センター
ＴＭＣシステムは１つ以上のアプリケーション層および／またはネットワーク層セキュリティ・システムと共にコンピュータ・システム上に常駐可能である。ＴＭＣ用の典型的なハードウエア構成には、アプリケーション層セキュリティ・システムに関して前述したと同様の容量を有するものでよいシステム・プロセッサおよびシステム・データ・ストアを含んでいる。典型的には、通信はインターネットのようなコンピュータ・ネットワークを介して行うことができる。しかし、直接接続およびダイアルアップ・アクセスを含む別の機構を介して１つ以上のシステムをＴＭＣに接続することができる。
【０１１６】
ＴＭＣは少なくとも１つの入力と、処理システムと、少なくとも１つの出力とを含んでいる。図１３はＴＭＣの例におけるルール作成工程の流れ図を示している。入力２００５はメッセージ、メッセージング・システム、攻撃、脆弱性、これらに関連する脅威、または当業者が脅威分析に関連すると思う他のいずれかの情報であることができる。加えて、１つ以上のアプリケーション層セキュリティ・システムによってＴＭＣへのフィードバックを行ってもよい。ＴＭＣ２０１０の最終的な出力は、アプリケーション層セキュリティ・システムによって判明し、または判明していない双方の脅威に対して防護するために利用できるルールおよび／または方針を含むことができる。これらのルールおよび／または方針２０１０は１つ以上のアプリケーション層セキュリティ・システムによって利用されることができる。
【０１１７】
好適な一実施形態では、ルールおよび方針の作成は受信された脅威情報の集合に基づいて行うことができる。情報は１つ以上のＭＳＳまたはＴＭＣと通信するように構成されたほかのいずれかの脅威情報源から受信することができる。
【０１１８】
ＴＭＣ２０１０の出力はルールおよび方針アプリケーション・プログラミング・インターフェース（ＡＰＩ）２０１５によって影響されることが可能である。図１３の実施例にはＡＰＩは１つしか示されていないが、所望の機能を果たすために複数個のＡＰＩを構成できることが当業者には理解されよう。ある実施形態では、ＡＰＩは脅威および／またはトラフィック・パターンの何らかの変化を考慮して必要な度に、または所望に応じて修正可能である。ＡＰＩはアプリケーション層セキュリティ・サーバーならびに標準的な侵入検出ルール・フォーマットの代わりにメッセージ質問システムに基づく所有者フォーマットを使用するようにプログラムまたは適応化が可能である。
【０１１９】
ある実施形態では、ルールおよび方針ＡＰＩの出力は自然言語であってよい。別の実施形態では、出力はそれらに限定されるものではないが、規則的表現、ＩＤＭＥＦのような侵入検出情報フォーマット、ＳＩＥＶＥのようなメール・フィルタリング、所有者ルール表現フォーマット、または当業者が適切であると見なすその他のフォーマットを含むルール表現言語であってよい。限定的ではない例として、示唆されたルールおよび方針でシステムをどのように構成するかを管理者またはユーザーに説明するために、自然言語出力を利用できる。
【０１２０】
ＡＰＩはＴＭＣによって作成された最終的なルールの集合を改良するために利用できる。限定的ではない例として、あるメッセージ・セキュリティ・システムは所有者ルール・フォーマットを使用する質問エンジンを含んでいる。このようなシステムでは、“ｔｈｒｅａｔ．ｅｘｅ”添付を伴う着信メッセージをブロックするルールは下記のように規定できる。
添付フィルタリング・ルール：
方向：着信
添付：ｔｈｒｅａｔ．ｅｘｅ
アクション：メッセージを破棄
限定的ではない例として、このようなシステムでの“脅威タイトル”件名を有する着信メッセージをブロックするルールは下記のように規定できる。
メール監視ルール：
方向：双方向
フィールド：件名
データ：脅威タイトル
アクション：メッセージを破棄
異なる実施形態は異なる種類のフィルタリングを行うために異なる種類のルールを用いることができる。ルールおよび方針ＡＰＩ２０１５が用いられる場合は、ルールおよび方針作成モジュール２０２０がＡＰＩと通信するようにプログラムまたは適応化されなければならない。
【０１２１】
ＴＭＣの出力２０１０は目標２０２５によって影響されることがある。目標２０２５はグローバル・目標、個々のメッセージング・セキュリティ・サーバー用の目標、または個々のユーザー用の目標であることができる。限定的ではない例として、あるＭＳＳはより保守的な脅威管理方針を有することができる。ある実施形態は自動的に整備されるルールを用いるように構成可能でき、一方、他の実施形態はローカル管理者によって認可されるルールを用いるように構成できる。ある状況では、不都合なコンテンツを破棄するルールを用いることが望ましく、別の状況ではそのコンテンツを隔離することが望ましいことがある。別の状況では、動作が行われる前に脅威の確率に対する信頼度が多少なりとも望ましいことがある。目標２０２５はグローバル目標でもよく、または異なるＭＳＳ用には別の目標でもよい例えば、スパム検出に９５％の有効率と９９．９％の精度を指定する目標をシステムに与えることができる。
【０１２２】
ある実施形態では、別の目標として、システムによって１人以上のユーザー、ＭＳＳ、またはその他のエンティティが脅威のある通信を定義できるようにすることが可能である。限定的ではない例として、スパムの場合、スパムは良好に定義し得ないことがある。二分決定だけが可能であるのではなく、本発明はメッセージを異なるカテゴリーに分類できる（例えばビジネスｅ−メール、個人ｅ−メール、チェーン・メール、アダルト言語、ポルノ、ウエブ製品の提供、ニューズレター、メーリング・リストなど）。ある実施形態では、個々のユーザー、管理者、またはその他の適宜の人またはコンピュータ化されたユーザーがこれらの種類のコンテンツのいずれかの受信に関する好みを登録することができる。次にシステムはそのエンティティ用の方針を実施する。これは後述し、図１４に示されている脅威プッシュバック・システムで有用であり得る。
【０１２３】
ルールおよび方針作成２０２０への入力は、それらに限定されるものではないが下記を含むことができる。
１．ＳｐａｍＡｒｃｈｉｖｅ．ｏｒｇのようなアーカイブからのスパムおよび非スパム・メッセージ、ユーザー報告スパム、個々のメッセージング・セキュリティ・システムによって識別されたスパム、分類ミスのメッセージに関する情報、分散チェックサム・クリアリングハウス（ｈｔｔｐ：／／ｗｗｗ．ｒｈｙｏｌｉｔｅ．ｃｏｍ／ａｎｔｉｓｐａｍ／ｄｃｃ）およびＲａｚｏｒ（ｈｔｔｐ：／／ｒａｚｏｒ．ｓｏｕｒｃｅｆｏｒｇｅ．ｎｅｔ）のような周知のスパム・データベースからの情報。
２．ウイルス定義ファイル、またはウイルス警報ニューズレター、および／またはウイルス警報データベースのような他のウイルス情報源からのウイルス情報。このシステムは形跡が得られる前にウイルス情報を生成するためにこの情報を利用できる。この情報は例えばアンチウイルス・メーカーであるＳｏｐｈｏｓおよびＭｃＡｆｅｅから入手可能である。この情報はＨＴＴＰ、ＦＴＰ、ＳＭＴＰを介して直接データベースにアクセスするか、他の適宜の手段で検索可能である。ある実施形態では、システムはウイルス定義ファイルが利用可能になる前にウイルスの蔓延をブロックし、ならびに他のアンチウイルス・システムが配備されていない場合の配備するためのルールを作成することができる。
３．侵入情報：この情報はバグトラック、ＣＥＲＴ、ソフトウエア・メーカー、オープン・ソースプロジェクト、ＦＢＩ  ＩｎｆｒａＧａｒｄのような情報共用プロジェクト、または適宜のその他のソースから抽出可能である。この情報はさらに分散侵入検出システムから検索可能であり、またはユーザーによる手動入力も可能である。
【０１２４】
システムは入力の種類およびソースに応じて入力のパージングおよび特徴抽出を行うことができる。スパン・メッセージの場合は、入力はマイクロソフトの．ｐｓｔフォーマット、ユニックスのｍｂｏｘフォーマット、転送されたスパムまたは添付ファイルとして送信されたスパム、スパム・メッセージのアーカイブ、またはその他のソースのような所有者フォーマットで記憶されているスパム・メッセージを含むことができる。スパム・メッセージはローカル記憶域、または、それらに限定されるものではないが、ＨＴＴＰ、ＳＣＰ、ＦＴＰ、ＰＯＰ、ＩＭＡＰ、またはＲＰＣのようなプロトコルを利用した遠隔記憶域からアクセス可能である。個々のメッセージについては、関連する特徴にはヘッダ、起点、およびメッセージ・コンテンツを含むことができる。各種の特徴は適宜に抽出し、記憶することができる。
【０１２５】
好適な一実施形態はメッセージをパーズし、特徴を抽出するために規則的表現コンテンツ整合ツールを使用できる。コンテンツ整合のために利用される規則的な表現を定義するプリフィルタを使用できる。これが抽出される特徴の種類を決定する。限定的ではない例として、メッセージ件名を抽出するため、件名の行だけを吟味するｒｅｇｅｘフィルタを使用することができる。全てのヘッダに関する情報を抽出するために、メッセージのヘッダだけを観測するｒｅｇｅｘフィルタを使用できる。同様に、本体から異なる種類のコンテンツを抽出するために別のプリフィルタを使用することができる。通常のトークナイザ・プリフィルタが通常のコンテンツの特徴を供給することができる。これらの特徴は語、語句、ｎ−グラム、または当業者が有用であると見なす他の特徴であってよい。プリフィルタはあるｅ−メール・アドレスおよびドメイン名を無視することを含めて、ある種の語に敏感であることができる。プリフィルタはさらに、特徴をｅ−メール・アドレス、ＵＲＬ、電話番号などに集束させることもできる。
【０１２６】
システムは敏感な特徴が確実に抽出されず、露出されないようにする匿名化モジュールを含むことができる。限定的ではない例として、匿名化モジュールはスパムの犠牲者およびドメインのＩＤを確定し、その情報の漏洩を防止することができる。
【０１２７】
ウイルス警報用には、入力は新たなウイルスまたはウオームの存在とプロパティを説明するｅ−メール・メッセージであってよい。入力パーサはこれらのメッセージをパーズし、関連する脅威のプロパティを決定するように構成できる。これらのプロパティは、それらに限定されるものではないが、添付の名称または種類、件名の行、および発信アドレス（ｆｒｏｍ  ａｄｄｒｅｓｓｅｓ）を含むことができる。入力パーサにはウイルス警報のソースが異なる場合は異なるフォーマット定義ファイル、またはプリフィルタを付与してもよい。あるいは、ウイルス警報パーサは他の情報にアクセスするためにウエブ・ページと通信することができる。この情報は関連するプロパティごとにパーズされることができる。別の実施形態では、ウイルス警報パーサはこのような情報を記憶するデータベースと直接インタラクトしてもよく、またはこのような情報に基づいてユーザーが手動的にデータをシステムに入力してもよい。
【０１２８】
ルール作成システム２０２０は単一のシステムに常駐してもよく、または複数の工程が複数のシステムで実行されてもよい。脅威情報は正規の形式および抽出された関連の特徴に還元されることができる。システムは関連の特徴を確定し、および／または特徴の集合を還元するために多様なアルゴリズムを利用することができる。ある実施形態では、配置された各特徴をＭＳＳ上の質問システムに関連付けることができる。ＴＭＣは作成される適宜の種類のルールを決定することができる。ある実施形態では、複数の質問システムを利用して特徴を表現することができる。ある実施形態では、特徴の集合が還元され、有効な種類のルールを作成できる。
【０１２９】
ある実施形態では、作成されたルールには重み付けがなされ、ある質問システムは特定のメッセージに関する全体的な脅威値にある程度の重みを有していてもよい。これらの値はシステムからの入力に基づいて決定することができる。したがって、これらの値は必要ならば、新たな脅威、ＭＳＳからのフィードバック、およびその他の適宜のソースに基づいて調整可能である。ＭＳＳは自動調整される重み、または各ルールおよび質問システムごとの信頼度、またはその他の関連情報に基づいて全体的な脅威の確率を判定するようにプログラム、または適応化可能である。好適な一実施形態では、ルール作成システム２０２０は新たな脅威情報を探すスケジューラを含むことができる。
【０１３０】
システムは先ず候補になる１組のルール３０３０の集合を作成する。これらが配信される前に、システムはこれらのルールの妥当性を判定するために目標ベースのテスト２０３５を利用できる。
【０１３１】
本発明のある実施形態はルールおよび方針をテストすることができる。テスト・データ２０４５は脅威データおよび非脅威データを含んでいてよい。システムはシステムの誤検出と見逃し、およびシステムの基本性能を発見するためにテスト・データの集合を利用することができる。ルール作成用に使用される目標２０４０はさらにテストへの入力として利用できる。性能上の目標を含むが、それに限定されない付加的な目標をテスト用に指定できる。指定された目標が達成されない場合は、システムは特徴の集合、個々の特徴の重み、各質問システムの重み、および目標に到達するための他のいずれかのパラメータを自動的に調整可能である。適切なチューニングが達成されると、ルールの集合が認可され、ＭＳＳに配信されることができる。
脅威プッシュバック・システム
公知のシステムの多くはローカルな環境の攻撃の兆候だけにしか対処しない。ＭＳＳのネットワークに加入している他のシステムを通知するほか、本発明のある実施形態は脅威の発生源を判定し、脅威を発生源の方向に押し戻すことができる。脅威の発生源が判定されると、システムはネットワークを経てメッセージを階層の他のシステムへと送信することができる。
【０１３２】
脅威プッシュバック・システムはアプリケーション・クライアント、アプリケーション層セキュリティ・システム、またはＴＭＣの一部として、またはそれらを補うものとしてコンピュータ・システムに常駐することができる。脅威プッシュバック・システムの典型的なハードウエア構成には、アプリケーション層セキュリティ・システムに関して本明細書で前述したと同じ容量を有するシステム・プロセッサおよびシステム・データ・ストアが含まれている。典型的には、通信はインターネットのようなコンピュータ・ネットワークを介して行われることができる。しかし、直接接続およびダイアルアップ・アクセスを含む１つ以上の他の機構を利用することもできる。
【０１３３】
図１４は脅威プッシュバック・システムの例を示している。２つの脅威認知モジュール３０３０，３０３５が示されている。脅威がローカルに検出されると３００５、脅威情報を脅威通知モジュール（ＴＮＭ）３０２０に送信可能である。ＴＮＭは脅威に関する情報を含む脅威通知３０４０を別のシステムの脅威検出モジュール３０２５に送ることができる。好適な実施形態では、ＭＳＳのＴＮＭは情報を別のＭＳＳに送ることができる。さらに別の実施形態では、クライアント・アプリケーション／システム、アプリケーション層セキュリティ・システムおよび／または脅威管理センター内の、またはこれらに接続されているようなネットワーク内のいずれかの位置にあるいずれかのＴＭＮは情報をネットワーク階層内の親に送ることができる。
【０１３４】
脅威通知プロトコルは関与しているシステム全体で標準化することができる。ある実施形態は脅威通知情報に応答するようにプログラムされ、または適応化された脅威応答モジュール３０１５を含むことができる。
【０１３５】
好適な実施形態では、本発明のシステムはアプリケーション層で機能するようにプログラムされ、または適応化されることができる。このような実施形態は容易に展開可能である。基礎になるネットワーク層プッシュバック・システムが動作している場合は、システムは脅威の経路を判定するためにその機能の一部を利用することができる。加えて、脅威通知システムは攻撃の発生源を判定することができる。限定されない例として、スパムの場合、攻撃発生源を判定するために、メッセージのヘッダを吟味しなければならない。システムはこれらのヘッダのうち幾つを信頼できるかを判定することができる。偽造されたヘッダを識別し、無視することができる。この工程はＩＰのレジスタのような外部データベース、およびＡＲＩＮのようなＡＳＮ番号、またはスパムハウスのようなスパム発生源のデータベースを参照することも含まれる。
【０１３６】
アタッカーは通信で示される経路情報を偽造することができるので、システムは適正な経路を決定するために利用可能な情報を処理することができる。これはアプリケーション・レベル情報、ネットワーク情報、またはＩＰトレースバック・システムのような外部システムからの情報、および当業者には知られているその他の資源のいずれかの組み合わせで達成可能である。アプリケーション・レベルでは、アタッカーはある識別情報を偽造できることがある。経路決定モジュールは経路情報を通知送信者モジュールに提供することができる。経路決定モジュールは経路抽出サブモジュールおよび経路確認サブモジュールを含むことができる。
【０１３７】
一実施形態では、経路抽出サブモジュールは識別情報をパーズし、これを経路情報として供給することができる。しかし、この情報は確認されておらず、不正確である場合がある。別の好適な実施形態では、経路確認モジュールは有効な経路情報を判定するために、抽出荒れた経路情報を処理することができる。限定的ではない例として、経路抽出サブモジュールはヘッダのようなメッセージ情報を読むことができる。戻り経路または受信ヘッダはメッセージが進行しタｅ−メール・サーバーの経路に関する情報を提供することができる。送信者のｅ−メール・アドレスを特定するために“ＦＲＯＭ（発信元）ヘッダを利用することができる。送信者のｅ−メール・アドレスを示すために“ＭＡＩＬ  ＦＲＯＭ（メール発信元）”ＲＦＣ８２１のヘッダを利用できる。送信者のドメインまたはホストネームを示すために“ＥＨＬＯ”ＲＦＣ８２１のヘッダを利用できる。メッセージのＩＤおよびメッセージの実際のコンテンツを含む他のヘッダおよびメッセージの特徴を利用してもよい。アクションの要請情報は返答メール・アドレス、郵便の宛先、または電話番号のような、受信者用に提供される接触情報である。メッセージ内のこの情報を利用できる。それに限定されるものではないがネットワーク接続のＩＰアドレスを含む当業者には知られているその他の情報も利用できる。
【０１３８】
情報の信憑性を判定するために幾つかの確認方法を利用できる。限定されない例として、上記のヘッダのほとんどは容易に偽造されるので、より信頼できるソースは戻り経路または受信ヘッダである。本発明の目標は可能な最長の本物の経路を判定することにある。本発明の一実施形態では、最後のヘッダだけが犠牲者のサーバーに接触した実際のサーバーであるので、このヘッダだけが使用される。受信された各ヘッダは受信元および受信者情報を含んでいる。これらの欄は適宜のＭＸレコード、Ａレコードおよび／またはリバースレコード、ならびに当業者に知られているその他の適宜のソースについてＤＮＳで確認することができる。これらのホストはオープンリレー・リスト、ダイアルアップ・アドレス・リストおよび判明しているスパム発生源リストについてチェック可能である。これらのリストのいずれかに存在することは正確に最後の受信ヘッダに関する付加的な情報を提供することができる。加えて、受信ヘッダの連鎖は互いに確認できる。この連鎖内での不一致によって、最後の正確な受信ヘッダに関する付加的な情報も得られる。これらのヘッダに関するその他の詳細は経路を確認するために利用できる。限定的ではない例として、日付情報およびサーバー・バージョン情報を利用できる。
【０１３９】
プッシュバック・メッセージを特定方向に送出する必要があることをシステムが判定すると、システムはプッシュバック・メッセージにどの情報を含めるべきであるのかを決定することができる。本発明の脅威情報はソースのＩＰアドレスに加えて、脅威に関する詳細な追加情報を含んでいる。
【０１４０】
詳細な脅威情報によってシステムは脅威に対してどのように反応するかに関するローカルな決定を下すことができる。限定的ではない例として、上記の脅威分類システムをスパム・メッセージの処理に利用できる。脅威プッシュバック・システムを介して送信されたスパム攻撃に関する情報は、脅威のカテゴリーおよびその他の関連する特性に関する情報を含むことができる。
【０１４１】
受信システムは組織レベルで通信のある部分をブロックするように構成できる。さらに、ＩＰＳはこの情報を利用して、それに限定されるものではないが不正なメッセージを含むあるカテゴリーのスパム・メッセージをブロックすることができよう。組織がチェーンレターおよびアダルト言語をブロックする方針を有することができるようにシステムを構成可能である。デスクトップ・レベルで、付加的にニューズレターやメーリング・リストをブロックするように、個人がシステムを構成することができる。それによって、スパムの共通の定義を必要とせずに、ブロックされたデータをできるだけソースに近いように共通に定義することが可能になる。
【０１４２】
脅威情報はその他のパラメータと共に脅威の存在を表示し、ソースを特定し、および／または詳細な脅威および／または応答情報を提供することができる。ソースを特定するため、提供される情報はそのＩＰアドレスまたはホストネーム、経路情報、判定された全経路情報のようなソースのＩＤを含むことができる。加えて、他のホストが独立して独自の抽出および／または確認を行うことができるように、経路情報を提供可能である。本発明のシステムはさらに、脅威であると判定されたトラフィックを表示して、経路上の受信者が記憶された情報から詳細を判定できるようにすることが可能である。本発明のこのシステムおよび方法はルーティング・システムで利用されるリバース・パス・フォワーディングの強化された形式である。
ホワイトリスト作成
一実施形態では、ホワイトリストに合致した通信は質問を受けないか、厳密な質問を受けないようにシステムを構成することができる。ホワイトリストが少なくとも１つのエントリを有すると、着信メッセージ質問システムがメッセージの質問と共にこのエントリを利用する。
【０１４３】
図１０はエントリを追加するためにホワイトリスト上で実行可能な操作を示している。発信アドレスが上記のいずれかの除外条件をパスすると１００５、これはホワイトリストに追加できる。ホワイトリストはＳＤＳ上に記憶しておくことができる。システムは先ず、アドレスがリスト上に既に存在するか否かを確認するためにチェックする１０１０。存在する場合は、リストをいずれかの新規の情報で更新可能である１０１５。新規の情報が更新される前に、システムはＳＤＳ内に充分なスペースがあるか否かをチェックできる１０２５。充分なスペースを利用できない場合は、ＳＤＳから追加スペースが割り当てられる１０３０。ホワイトリストにアドレスが見つからない場合は、そのアドレスに初期のレコードを追加できる。ホワイトリストに新規のアドレスが追加される１０４０前に、システムはＳＤＳ内に充分なスペースがあるか否かをチェックできる１０２０。充分なスペースを利用できない場合は、ＳＤＳから追加スペースが割り当てられる１０３５。多くの実施形態で、明示的なスペースの割り当てが行われる必要はなく、むしろ情報の更新１０１５、またはエントリの追加１０４０の結果、暗黙的なスペースの割り当てが行われる。
【０１４４】
アウトバウンド・アドレス用の初期レコードはｅ−メール・アドレス、内部ｅ−メール・アドレス、メッセージ送信時間、利用回数カウント、最終利用時間および／または関連がある、または有用であると当業者がみなしたその他のいずれかの特性を含むことができる。ホワイトリスト上に既に存在するｅ−メール・アドレスの場合、システムは合うとバウンド・アドレスとして利用されているｅ−メール・アドレスの各々のインスタンスごとに別個のレコードを利用することができ、またはシステムは利用のインスタンスを記述する情報を含め、そのエントリ内の情報の一覧と共に各アウトバウンド・アドレスごとに単一のレコードを保存することができる。システムは、異なるデータ構造を利用した他の多くの方法でレコードを記憶することができる。レコードはｅ−メール・アドレスに加えて、それに限定されるものではないがｅ−メール・アドレスのハッシュを含む他のデータ表現を含んでいてもよい。
【０１４５】
好適な実施形態では、システムはレコードをＭｙＳＱＬデータベースに記憶することができる。限定的ではない例として、外部および内部のｅ−メール・アドレス、最後の更新日、出現カウンタから構成されたデータベースを構築するために下記のコマンドを使用できる。
Create table ctwhitelist
(out emailaddress  可変長（２５５）非ゼロ  −外部ｅ−メール・アドレス
in emailaddress    可変長（２５５）非ゼロ  −内部ｅ−メール・アドレス
lastupdatetime    日時                      −このアドレスの最終更新
occr count        整数                      −アドレス出現カウンタ
ホワイトリストの保存
ある実施形態では、システムによって無制限の記憶が可能になる。別の実施形態ではリスト用に利用できる記憶装置を制限することができる。さらに別の実施形態では、システムによってリストのサイズ管理が可能になる。それに限定されるものではないが、先入れ先出し法および最も長期間参照されていない方式（ＬＲＵ）を含む多くのキャッシング（ｃａｃｈｉｎｇ）技術を利用できる。その他の技術にはアウトバウンド・アドレスを報告した内部ユーザー数の感情を含むことができる。リストの一掃はリアルタイムで、または周期的に行うことができる。加えて、本発明によってホワイトリストを管理するために広範なリスト管理技術を利用できることが当業者には理解されよう。
ホワイトリストの利用
本発明によるホワイトリストを使用したシステムの例が図９に示されている。インバウンド通信９０５の１つ以上の関連パラメータが１つ以上のホワイトリスト９１０と比較される。ある実施形態では、ホワイトリストは着信した各ｅ−メール・メッセージごとにチェックされる。好適な実施形態では、比較には発信元アドレスが含まれる。ホワイトリスト９０１に対するチェックの結果、一致がないことが明らかになると、メッセージは通常のメッセージ質問９１５を受ける。通常のメッセージ質問は、前述のようにスパムまたはその他の脅威に最も敏感な分析基準を用いることができる。メッセージが通常の質問９１５にパスすると、すなわちそれがスパムでも脅威でもないこと（またはスパムまたは脅威である確率が低いこと）が判明すると、それは対象となる受信者に配信９２０用に提示されることができる。ホワイトリスト９１０に対するチェックの結果、一致が判明すると、多様な方法でメッセージを処理するようにシステムを構成できる。一実施形態では、どのメッセージ質問をも迂回して９２５、メッセージを対象となる受信者９２０に配信するようにシステムをプログラムまたはアレンジすることができる。代替実施形態では、適応性があるメッセージ質問９３０を利用してメッセージを処理するようにシステムをプログラムまたはアレンジすることができる。メッセージがスパムではないことを適応メッセージ質問９３０が判定すると、これはメッセージを配信９２０用に送出することができる。
【０１４６】
ある実施形態では、双方のオプション９２５、９３０を選択的に利用できる。ホワイトリストに載せられた通信を適応メッセージ質問９３０にかけるのか、どのメッセージ質問９２５をも迂回するのかの決定は展開に応じて下すことができ、またはホワイトリスト・エントリの詳細に基づいて行うことができる。例えば、より頻繁に使用されるアウトバウンド・アドレスからのメッセージは質問を完全に迂回し９２５、一方、それほど頻繁に使用されていないアウトバウンド・アドレスからのメッセージは適応メッセージ質問９３０にかけることができる。
【０１４７】
メッセージがホワイトリスト情報と共に通常の質問、または適応質問を通過すると、質問モジュールは質問の種類および／またはレベルを確定するためにホワイトリスト情報を利用することができる。好適な一実施形態では、適応メッセージ質問は図１１を参照してさらに記載するように、複数のレベルの信頼性を利用することができる。別の実施形態では、適応メッセージ質問は質問器が特徴として持っている信頼度を示す信頼度表示器をセットすることができる。
【０１４８】
対象とされる受信者に配信されないメッセージは隔離または削除される。代替実施形態では、スパムであると判定されたメッセージはスパムまたは脅威であると表示され、対象とされる受信者に送出されることができる。
【０１４９】
加えて、アウトバウンドされた各ｅ−メール・アドレスに信頼度の数値を割り当て可能である。所定の着信ｅ−メール・アドレスに関連する信頼度の値に応じて、着信メッセージに様々なレベルの質問を課すことができる。好適な一実施形態では、より低い信頼度の値に関連する着信メッセージにはより攻撃的なスパム質問が課され、より高い信頼度の値に関連する着信メッセージには攻撃性が低いスパム質問が課される。別の実施形態では、信頼度の値に基づくいずれかの負のスパム検出ポイントを相殺するために、メッセージに所定の正の信頼（ｐｏｓｉｔｉｖｅ  ｃｒｅｄｉｔ）を与えることができる。
【０１５０】
システムの好適な一実施形態によって外部ｅ−メール受信者の一部または全部をホワイトリスト９３５に載せることが可能になる。ある実施形態は特定のｅ−メール・アドレスへの発信メッセージ数を記述するメトリックを有することができる。メトリックがある閾値に達すると、ｅ−メール・アドレスはホワイトリストにリストされることができる。他の実施形態は時間を経てアドレスをトラッキングする能力を含むことができる。これらの実施形態では、特定の時間中にメトリックがアウトバウンドの特定のｅ−メール・アドレスの一定の値を超えると、そのエントリはホワイトリストにリストされることができる。
【０１５１】
上記のパラメータは適宜のインターフェースを介してアプリケーション管理者によって構成可能であってよい。ある実施形態は固定されたパラメータをサポートすることがあるが、これらよりもアプリケーション管理者の構成が優先されてもよい。
【０１５２】
ある実施形態では、スパムまたは脅威として特徴付ける閾値は、以前に受信された通信に関連するデータに基づいて動的に決定されてもよい。あるいは、個々のアドレスに関する特定の閾値を構成できるように、アプリケーション管理者にインターフェースを供給してもよい。ある実施形態では、アプリケーション管理者によって特別に構成されていない限り、デフォールトによる閾値を動的に導出してもよい。
【０１５３】
スパムまたは脅威が検出されると、通知の代わりに、またはそれに加えて、１つ以上の応答手段をトリガすることができよう。このような応答手段は受信された通信のソースからのそれ以上の通信の受け入れ拒否、通信の隔離、通信が対象となる受信者に送出されるようにするための通信のストリッピング、および／またはあるソースからの過剰な数の着信通信の抑制を含むことができよう。
認証されたホワイトリスト
ホワイトリストに関する問題の１つは、アタッカーまたはスパム送信者がメッセージをホワイトリストにあるアドレスから送信したものと見せかけ、それによってフィルタリングおよびアンチスパム・ツールを迂回できることである。アタッカーがメッセージ上の送信者情報を偽造することは比較的容易である。ホワイトリストのこのような限界を克服するため、本発明のシステムによって送信者情報の認証が可能である。送信者認証をホワイトリスト・システムと統合するには幾つかの方法がある。一実施形態では、認証された送信者だけがホワイトリストにリストされることができる。このような手順は偽造された送信者がホワイトリストに載る確率を低下させることができる。しかし多くの環境では、認証されるメッセージの比率は低いので、ホワイトリスト作成の有効性が低下する。本発明のある実施形態によって、認証された送信者と認証されない送信者の双方がホワイトリストに載ることが可能になる。これらの実施形態では、認証された送信者からのメッセージにより高い信頼度の値が与えられる。ＳＭＩＭＥおよびＰＧＰは認証を与える機構を提供する。
【０１５４】
このような実施形態の１つが図１１に示されている。限定されない例として、メッセージ１１０５がホワイトリスト１１１５上の送信者から受信されると、関連する信頼度のレベルが検索または計算される１１３５。ある実施形態では、信頼度のレベルは、単に再検索を必要とするだけのホワイトリスト・エントリに関連する単一の値である。別の実施形態では、信頼度レベルの値はエントリの様々な特徴の重み付の総計として計算可能である。このような実施形態のあるものでは、重みは静的に定義され、デフォールトでユーザーまたはその他のコンピュータ・システムによって無効にされるか、または動的に構成可能である。関連する信頼度レベルは閾値レベル１１４０と比較可能である。信頼度レベルの閾値と一致するか、それ以上の信頼度レベルを有する通信はいずれもメッセージ質問１１２０を迂回することができ、一方、充分なレベルの信頼度を有していない通信は少なくとも幾つかの質問１１２５で処理される。質問を迂回するメッセージ１１２０ならびに質問にパスしたメッセージ１１２５は対象となる受信者に配信されることができる１１４５。このような実施形態では、ホワイトリスト・エントリに関連しないメッセージには質問およびそれ以降の処理が課せられる１１５０。
【０１５５】
本発明のある実施形態では信頼度レベルの閾値１１３０を管理者、システムの別のユーザー、または他のコンピュータ・システムによって構成可能である。
ホワイトリストからの除外条件
本発明によるスパム／脅威検出は全てのアウトバウンド・メッセージを吟味し、判明しているアウトバウンドのｅ−メール・アドレスのリストを保存する。結果として生じたリストは次に信頼できる送信者のリストとして利用可能である。しかし、全てのアウトバウンド・メッセージをあらゆる場合に着信メール用の信頼できる送信者リストに加えることは必ずしも推奨できないことがある。例えば、ユーザーがニュースグループにメッセージを送信することがあるが、それはこのニュースグループからのメッセージが必ずしもメール・フィルタリングを迂回することを示すものではない。さらに説明すると、ユーザーは配信解除メッセージをニューズレターに、またはスパム・メッセージに応答して送信することがある。このように、無条件のホワイトリスト追加を推奨できない状況があり得る。本発明のシステムによってある除外条件を入力出力、適用することが可能である。
【０１５６】
これらの除外条件にはルール集合、経験則、人工知能、決定ツリー、またはそれらのいずれかの組み合わせが含まれる。条件は管理者、またはシステムの他のユーザーによって設定可能である。
電子通信の質問への多重待ち行列アプローチ
図７を参照すると、受信された通信に複数のリスク査定を行うための多重待ち行列アプローチが提示されている。
【０１５７】
メッセージは先ず高度な処理および管理のための、ＳＤＳの一部である未処理メッセージ・ストア７３０に格納される。メッセージは外部ソース７４０から着信し、このストア７３０に格納される。このストア７３０は工程の終了までメッセージへの物理的制御を維持し、またはメッセージが質問基準をパスしない場合は、隔離される。
【０１５８】
インデックスはメッセージ自体より大幅に小さいので、安定性と性能を高めるために、ストア７３０内でのメッセージへのインデックスは、実際のメッセージ自体の代わりに待ち行列層７２０内の各待ち行列７７１Ｂ、７８１Ｂ−７８４Ｂ、７９１Ｂを通過して質問エンジン７７１Ａ、７８１Ａ−７８４Ａ、７９１Ａへと送られるために使用される。
【０１５９】
待ち行列および質問エンジンの双方とも、メッセージ上でアクションを行うために未処理メッセージのストア７３０内の実際のメッセージを再指示するためにインデックスを用いる。受信されたメッセージまたは通信にインデックスを割り当てるために、適宜の任意のインデックス割り当てアプローチを利用してよい。例えば最初に受信された通信の場合は０のような、ある定められたインデックスから始まる増分するインデックスを以前に受信された通信に割り当てりことによってインデックスの割り当てを行ってもよい。充分に大きいインデックスが割り当てられた後は、インデックスは定められた基点にリセットすることができよう。ある実施形態では、通信の種類、着信時間などのような受信された通信の特徴に基づいてインデックスが割り当てられてもよい。
【０１６０】
このアプローチは複数の脅威にさらされた多重処理方式を利用してメッセージを独立的に処理し、それによって、複数の脅威にさらされた多重処理アプローチ電子通信大容量のメッセージを処理するスケーラブルな機構が得られる。
【０１６１】
メッセージを独立して処理することによって、待ち行列層７２０は、既存の待ち行列上のメッセージにインデックスを付し、または新たな待ち行列を作成し、その待ち行列上のメッセージ上にインデックスを付すことによって最も効率的な処理手段を決定する。新たな待ち行列が作成される場合は、その新規の待ち行列に作用する特定の種類の質問エンジンが作成される。
【０１６２】
待ち行列は拡張性および管理のために動的に追加、削除できる。好適な一実施形態では、アプリケーション管理者は起動時にシステムによって利用される元の数の待ち行列を構成することができる。管理者はさらに、性能および管理上の目的で特定の待ち行列、または特定種類の待ち行列を動的に削除または追加する能力を有している。各待ち行列は、複数の待ち行列および複数の処理工程が存在することができる特定の質問エンジンに関連している。
【０１６３】
所有者アプリケーション特有のエンジンは、コンテンツのフィルタリング、ルールをベースにした方針遂行、および誤用防止などを行うために各待ち行列に作用することができる。緩やかに結合されたシステムによって、所有者アプリケーション特有のアプリケーションの機能強化を増強可能である。
【０１６４】
この設計によって、メッセージ質問の適応された方法が提供される。アプリケーション特有エンジンは、コンテンツの質問を完遂するため未処理メッセージ・ストア内のメッセージへのインデックスを介してメッセージに作用する。
【０１６５】
待ち行列の管理によって、アプリケーション管理者によるアクセスおよび管理を容易にするためにＷｅｂ、ｅ−メールのような適宜のインターフェースおよび／または前述のような電話をベースにしたインターフェースを介してメッセージの詳細が検索される。待ち行列の管理によって、管理者の特定のネットワークおよびシステム構成のニーズに最適になるようにシステムの特性をカスタマイズするため、管理者は（システム・デフォールト以外の）メッセージ待ち行列の順番を選択することができる。
【０１６６】
図８Ａ−８Ｂは受信された通信に関連するリスク査定への多重待ち行列アプローチの利用を示した流れ図である。段階８０２で、工程の指導が開始されるか否かの決定が下される。そうである場合は、ＳＤＳから適宜の構成ファイルを読み出すために段階８０５および８０７が実行され、質問エンジンの種類、数、および順序が決定され、適宜の待ち行列およびインスタンスが作成される。否である場合は、工程は段階８１０で通信の受信を待機する。
【０１６７】
段階８１２で受信すると、通信は未処理メッセージ・ストアと呼ばれるＳＤＳの部分に記憶される。通信には段階８１５で、未処理メッセージ・ストア内でその通信を一意的に識別するためのインデックスが割り当てられ、このインデックスは順序付けの制約に基づいて第一の待ち行列内に配される。
【０１６８】
段階８１０で行われる通信の受信を待機する工程は、この工程のさらに別の段階とは関わりなく継続され、その結果、受信された各通信が流れ図の残りの部分を新たに横切ることが引き起こされる。ある実施形態では、段階８１０の複数のインスタンスが通信の受信を同時に待機してもよい。
【０１６９】
ある実施形態では、追加の質問エンジンおよび関連する待ち行列を開始すべきであるか否を判定するため、通信の受信によって負荷の評価がトリガされてもよい。別の実施形態では、別個の工程がこの負荷分析を周期的および／またはアプリケーション管理者の指示によって行われてもよい。
【０１７０】
インデックスは、段階８２５で判定された結果、待ち行列に関連する質問エンジンによって質問される準備ができるまで待ち行列８２０を移動する。この増分的な移動は質問の準備ができるまで段階８２０と８２５の間のループとして示されている。段階８２５で通信が評価される準備が完了していない場合は、その通信は段階８２０で待ち行列を通って移動し続ける。通信が準備完了である場合は、図８Ｂの段階８３０で適宜の質問エンジンにインデックスが付与される。
【０１７１】
質問エンジンは段階８３０でそのインデックスに基づいて通信を処理する。段階８３５で質問が完了すると、質問エンジンは質問に基づいて受信された通信に関連する新規のリスク・プロファイルを作成する。
【０１７２】
追加の質問が行われる場合は（段階８４０）、通信のインデックスは段階８４５で次の種類の質問のインスタンス用の待ち行列に配される。インデックスはこの次の待ち行列を移動すると、段階８２０での工程が続く。
【０１７３】
これ以上の質問が要求されない場合は（段階８４０）、段階８５０で通信が全ての適宜のエンジンによる質問にパスしたか否かを判定するためのチェックがさらに行われる。通信が全ての質問にパスした場合は、通信は段階８５５で宛先へと送出され、段階８７０でこの通信の終了に関して処理される。
【０１７４】
段階８５０での判定の結果、通信が１つ以上の質問に失敗した場合は、段階８６０で失敗時処理が行われる。適宜の失敗時処理が完了すると、段階８７０でこの通信の終了に関して処理される。
【０１７５】
失敗時処理には多様な通知および／または修正手段を含めることができる。このような通知および／または修正手段は前述の、および以上検出に関連して下記に詳細に記載するような手段を含んでいてもよい。
異常検出工程
本発明の実施例による異常検出工程は図６に示すように３つの構成要素を使用する。
１．収集エンジン
これは実際のデータ収集が行われる所である。収集エンジンはアプリケーション・サーバーに向けられた、またはそこから発信された通信を受信する。受信された通信には１つ以上のテストが課される。これらの１つ以上のテストは上記の様々なリスク査定に対応するものでよい。
【０１７６】
図６に示したような好適な一実施形態の収集エンジンは上記の多重待ち行列アプローチを利用する。しかし、この特定の収集エンジン・アーキテクチャは、この異常検出工程の文脈内で使用可能な収集エンジンに関して限定的であるのではなく、例示目的である。
【０１７７】
図６に示されるように、収集エンジンは質問層６１０内の１種類以上の１つ以上の質問エンジンを含んでいる。待ち行列層６２０内の各種の質問エンジンには、関連する種類の質問エンジンによる質問を待機する受信された通信のインデックスを含む少なくとも１つのインデックス待ち行列が関連している。待ち行列６２０と質問層６１０とは全体として収集エンジンを形成する。受信された通信は受信され、ＳＤＳ内に記憶され、インデックスが付される。インデックスは収集エンジンミ夜処理を待ち行列内で待機する。
２．分析エンジン
以前の構成要素によって収集されたデータは以上検出エンジン６４０によって異常な活動について分析される。分析は以前受信された通信の分析から時間を経手累積されたデータに基づいて行われる。動的に導出された、または所定の閾値を用いて異常を検出するために１組の所定の経験則を利用してもよい。あらゆる種類のインターネット・アプリケーション通信用に多様な種類の異常を一般的に定義できるが、一方では、他の異常はｅ−メールまたはｗｅｂのような特定の種類のアプリケーション向けだけに定義できる。以前に受信された通信および適宜の構成データ６３０はＳＤＳに記憶される。
【０１７８】
分析エンジンが検出する異常の種類の集合は、判明している種類の異常のより大きい集合から選択してもよい。対象となる集合はコンパイル時間に設定されてもよく、または実行時間に構成可能であり、またはある実施形態での実行中でもよい。設定アプローチを利用する実施形態では、あらゆる種類の異常および構成情報が分析エンジン内で設定される。このような実施形態のあるものでは、受信された通信の種類に応じて異なる異常の集合が対象になる。実行時間に構成可能な実施形態では、異常の種類が構成ファイルから読み出され、または分析エンジンの実行時間に対話式に構成される。設定アプローチの場合と同様に、ある種の異常性は選択された種類の通信に関してだけ対象となることができる。最後に、（ある設定または構成可能な実施形態を含む）ある実施形態では、上記のようなインターフェースが供給されて、分析エンジンの実行中に、対象となる種類の異常およびこれに関連するパラメータを再構成できるようにしてもよい。
【０１７９】
様々な種類の異常の閾値は以前に受信された通信に関連するデータに基づいて動的に決定してもよい。あるいは、個々の種類の異常に関して特定の閾値を構成できるインターフェースをアプリケーション管理者に供給してもよい。ある実施形態では、デフォールトによる閾値はアプリケーション管理者によって特別に構成されない限り、動的に導出してもよい。
【０１８０】
異常は典型的には特定の期間をベースにして検出される。このような期間は特定の固定期間（例えば先月、昨日、去年、セキュリティ・デバイスの最後の再起動以来など）であってよく、全ての種類の異常に適用される。あるいは、アプリケーション管理者によって上記のような適宜のインターフェースを介してあらゆる種類の異常性、または各種の異常性ごとに個別にそれぞれの期間を構成することもできる。ある実施形態はあらゆる種類の異常性、または各種の異常性ごとに個別に固定期間のデフォールトをサポートしてもよく、これはアプリケーション管理者の構成によって無効にされることができる。
【０１８１】
好適な一実施形態では、図６に示すように、収集エンジンによって作成されたリスク・プロフィル６４２、６４４、６４６からの情報が、対象となる種類の異常の獲得された閾値と比較される。これらの比較に基づいて、受信された通信が異常であるか否かの判定がくだされ、異常である場合は、通信がどのように（異常の種類）異常であるかが判定される。
【０１８２】
好適な一実施形態では、受信された通信に関連する記憶されたリスク・プロファイルが同じ種類の以前に受信された通信に関連するデータと統合される。次に、この新規の統合されたデータ集合が後続のその種類の受信された通信の分析に利用される。
【０１８３】
異常が検出されると、異常表示信号が出力される。出力された信号は検出された異常の種類、および異常が検出された通信を特定する警報データ６５０のようなデータを含んでいてもよい。ｅ−メール・アプリケーション・セキュリティに関する様々な種類の異常を以下に記載する。これらの種類の異常は、以下に記載し、または前述の代替の異常検出アプローチのいずれかを利用して検出できる。
３．アクション・エンジン
分析に基づいて、この構成部品はどの種類のアクションがトリガされる必要があるかを決定する。一般に、アクションには進行中の異常な活動を管理者に警報することが含まれている。警報エンジン６６０はいずれかの適宜の通知を行い、および／またはいずれか適宜の修正アクションを開始することによってこのタスクを実行する。
【０１８４】
出力された信号はある実施形態ではさらに別の応答をトリガする。あるいは、出力された信号が応答であってもよい。好適な一実施形態では、出力された信号は１つ以上のそれぞれ特定された配信プラットフォームを介して１人以上の指定の受信者に対する通知であってよい。例えば、通知はｅ−メール・メッセージ、ページ、ファクシミリ、ＳＮＭＰ警報、ＳＭＳメッセージ、ＷＡＰ警報、音声通話またはその他の適宜なメッセージで警告するＯＰＳＥＣ（オペレーション・セキュリティ）の形態のものでよい。あるいは、このような通知は出力された信号によってトリガされることもできよう。
【０１８５】
通知の代わりに、または通知に加えて、出力された信号によって１つ以上の修正手段がトリガ可能であろう。このような修正手段には受信された通信のソースからのそれ以上の通信の受信拒否、通信の隔離、アプリケーション・サーバーによって安全に処理されるようにするための通信のストリッピング、および／または毎秒ごとの過剰な数の着信接続を、内部アプリケーション・サーバーによってメッセージング可能なレベルまで抑制することを含めることができよう。
【０１８６】
好適な一実施形態では、アプリケーション管理者が所望の応答を選択的に構成でき、構成されたこの応答を特定の種類の異常と関連付けることによって、その種類の異常が検出されると、構成された応答が行われるようにするインターフェースを備えてもよい。
【０１８７】
図４は本発明の好適な一実施形態による典型的な異常検出工程の流れ図を示す。工程は段階４１０で、異常の種類、これらの種類の閾値、および以前のデータが考慮されるべき期間を含む処理上の様々な制約を初期設定することによって開始される。この情報は初期設定段階で対話式に構成できる。対話式の構成に加えて、またはその代わりに、以前記憶された構成情報をＳＤＳからロードしてもよい。
【０１８８】
工程は段階４２０で継続され、そこで異常定義情報（例えば１５分の期間内に同じ添付ファイルを有する着信メッセージ）が読み出される。次に、新たなスレッドが必要であるか否かが判定される。この判定は異常の詳細を読み込むこと（段階は示さず）に基づいて行われる。段階４３０で、新たなスレッドが必要な場合は、スレッドは段階４５０で処理されるように紡がれる（ｔｈｅ  ｔｈｒｅａｄ  ｉｓ  ｓｐｕｎ）。段階４４０で、工程は異常に冠する情報を読み出すために段階４２０に戻るまで特定期間だけ休止する。
【０１８９】
段階４５０で新規のスレッドの処理が開始されると、異常を評価するために必要な情報がＳＤＳ内の適宜の記憶域から検索され、必要ならば操作され、段階４６０で分析される。段階４７０での判定は異常を検出するために行われる。好適な一実施形態では、この段階は判定を下すために所定の閾値を用いる。このような所定の閾値は対話式に、または構成ファイルを介して供給されることができよう。以上が検出されない場合は、工程は停止される。
【０１９０】
異常が検出されると段階４８０で異常表示信号が出力され、その結果、通知がなされてもよい。可能性がある異常検出の結果はアクション・エンジンに関連して上記に詳細に記載されている。
【０１９１】
異常の種類は特定のアプリケーション・サーバーの種類と性質によって変化することがある。以下の記述はｅ−メールが問題のアプリケーション文脈である、異常の定義例を示す。これらに類似する、または同一の異常は別の種類のアプリケーション・サーバーに対して定義可能である。
【０１９２】
ｅ−メール・システムには潜在的に多くの種類の異常がある。分析は収集されたデータ、および経験則で監査されたデータに基づく正常さについての動的なルールに基づいて行われる。ある実施形態では、アプリケーション管理者に対して、異なる種類の異常性に対する所定のルールを構成するためのインターフェースを供給することができる。図５はこのようなインターフェース用のサンプル・スクリーンを示している。インターフェースの機能はセキュリティ強化デバイス上で動作するＷｅｂサーバー、または前述のような適宜のインターフェース・プラットフォームを介して供給されることができる。
【０１９３】
好適な一実施形態では、各分析用の閾値は異常アクション・テーブルから導出される。各異常ごとのアクションもこのテーブルから取り出される。分析は何らかの異常が発生したことを特定し、アクション・モジュールに委託する。ｅ−メールに関して様々な種類の異常を下記に列挙する。
【０１９４】
１．同じＩＰアドレスからのメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージの発信元であるＩＰアドレスに関する情報を有している。ＩＰアドレスはＳＤＳ内に記憶される。この異常の判定基準は、所定期間で同じＩＰアドレスからのメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０１９５】
２．同じアドレス（ＭＡＩＬ  ＦＲＯＭ）からのメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージの発信元であるアドレス（ＭＡＩＬ  ＦＲＯＭ）に関する情報を有している。判定されたアドレスはＳＤＳ内に記憶される。この異常の判定基準は、所定期間で同じＭＡＩＬ  ＦＲＯＭアドレスからのメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０１９６】
３．同じサイズを有するメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージのサイズに関する情報を有している。メッセージのサイズはＳＤＳに記憶される。このサイズはメッセージ本体のサイズのことであり、ヘッダのサイズは含まれない。この異常の判定基準は、所定期間で同じサイズのメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０１９７】
４．同じ件名を有するメッセージ−この異常の収集ポイントはＳＭＴＰＩ／ＳＭＴＰＩＳサービスである。ＳＭＴＰＩ／ＳＭＴＰＩＳはメッセージの件名の行に関する情報を有している。メッセージの件名行の情報はＳＤＳに記憶される。この異常の判定基準は、所定期間で同じ件名行を有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０１９８】
５．同じ添付名を有するメッセージ−この異常の収集ポイントはＭＩＭＥ  Ｒｉｐｐｅｒ待ち行列である。ＭＩＭＥ  Ｒｉｐｐｅｒ待ち行列は実際のメッセージを構成要素のＭＩＭＥ部分へとパーズし、この情報をＳＤＳに記憶する。この情報の一部は添付ファイル名である。この異常の判定基準は、所定期間で同じ添付名を有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０１９９】
６．同じ添付拡張を有するメッセージ−同じ添付名を有するメッセージ−この異常の収集ポイントはＭＩＭＥ  Ｒｉｐｐｅｒ待ち行列である。ＭＩＭＥ  Ｒｉｐｐｅｒ待ち行列は実際のメッセージを構成要素のＭＩＭＥ部分へとパーズし、この情報をＳＤＳに記憶する。この情報の一部は添付ファイル拡張である。この異常の判定基準は、所定期間で同じ拡張を有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０２００】
７．ウイルスを有するメッセージ−この異常はいずれかのアンチウイルス待ち行列がイネーブルされた場合だけ検出される。この異常の収集ポイントはアンチウイルス待ち行列である。アンチウイルス待ち行列はメッセージの個々のＭＩＭＥ部分上のいずれかのウイルスを走査する。走査の詳細はＳＤＳに記憶される。この異常の判定基準は、所定期間でウイルスを有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０２０１】
８．同じウイルスを有するメッセージ−この異常はいずれかのアンチウイルス待ち行列がイネーブルされた場合だけ検出される。この異常の収集ポイントはアンチウイルス待ち行列である。アンチウイルス待ち行列はメッセージの個々のＭＩＭＥ部分上のいずれかのウイルスを走査する。走査の詳細はＳＤＳに入力される。この情報の一部はウイルス名である。この異常の判定基準は、所定期間で同じウイルスを有するメッセージ数が閾値以上であることである。閾値のレベルに基づいて、適宜の警報が発生される。
【０２０２】
下記の表はこの情報をＳＤＳに記憶するためにリレーショナル・データベースを利用した好適な一実施形態の異常テーブルの欄を示している。
【０２０３】
【表２−１】
2005520230.tif 000005
【０２０４】
【表２−２】
2005520230.tif 000006
【０２０５】
下記の表はこの情報をＳＤＳに記憶するためにリレーショナル・データベースを利用した好適な一実施形態の異常アクション・テーブルの欄を示している。
【０２０６】
【表３】
2005520230.tif 000007
【０２０７】
本件出願を通して、様々な刊行物が参照された。これらの刊行物の開示内容は本発明が関与する技術水準をより充分に記載するために全体が参照によって本明細書に組み込まれている。
【０２０８】
上記の実施形態は例示目的のみで開示されたものである。本発明から離れることなく、本明細書に開示された特定の実施形態に多くの変更が可能であることが当業者には容易に理解されよう。したがって、本発明の範囲は上記に記載の特定の実施形態に限定されるものではなく、下記の特許請求の範囲によって決定されるべきものである。
【図面の簡単な説明】
【０２０９】
本明細書に組み込まれ、その一部を構成する添付図面は、本発明の実施形態を図示し、記載内容と共に本発明の原理を説明する役割を果たす。
【図１】図１は典型的な従来技術のアクセス環境を示す。
【図２】図２は本発明による好適な一実施形態を用いた環境のハードウエア図を示す。
【図３】図３は本発明の典型的な実施形態の構成要素の論理構成図である。
【図４】図４は本発明による異常検出工程の例の流れ図である。
【図５】図５は異常検出構造インターフェース・スクリーンのサンプルである。
【図６】図６は本発明による請求項強化システムの実施例のアーキテクチャを示す構成図である。
【図７】図７は受信された通信に対する複数のリスク査定のアプリケーションを管理するために複数の待ち行列を利用した、本発明によるリスク査定の実施例のアーキテクチャを示す構成図である。
【図８Ａ】図８Ａは図７に示したアーキテクチャを用いた、受信された通信に関連するリスク査定工程を示す流れ図である。
【図８Ｂ】図８Ｂは図７に示したアーキテクチャを用いた、受信された通信に関連するリスク査定工程を示す流れ図である。
【図９】図９は本発明による通信査定工程の実施例の流れ図である。
【図１０】図１０は本発明によるホワイトリスト管理工程の流れ図である。
【図１１】図１１は本発明による質問工程の実施例の流れ図である。
【図１２】図１２は脅威管理アーキテクチャの好適な実施形態を通る情報の流れの概要を示す。
【図１３】図１３は本発明による好適な一実施形態を用いた脅威管理センター（ＴＭＣ）の構成図を示す。
【図１４】図１４は本発明による好適な一実施形態を用いた脅威プッシュバック・システムの実施例を示す。
【図１５】図１５は本発明による典型的な個人メッセージング・セキュリティ・システム（またはアプリケーション層セキュリティ・システム）の構成要素を示す。
【図１６】図１６は本発明によるセキュア配信工程の実施例の流れ図である。
【図１７】図１７は本発明によるセキュア配信工程の実施例の別の流れ図である。
【図１】
2005520230.tif 000008
【図２】
2005520230.tif 000009
【図３】
2005520230.tif 000010
【図４】
2005520230.tif 000011
【図５】
2005520230.tif 000012
【図６】
2005520230.tif 000013
【図７】
2005520230.tif 000014
【図８Ａ】
2005520230.tif 000015
【図８Ｂ】
2005520230.tif 000016
【図９】
2005520230.tif 000017
【図１０】
2005520230.tif 000018
【図１１】
2005520230.tif 000019
【図１２】
2005520230.tif 000020
【図１３】
2005520230.tif 000021
【図１４】
2005520230.tif 000022
【図１５】
2005520230.tif 000023
【図１６】
2005520230.tif 000024
【図１７】
2005520230.tif 000025
【国際調査報告】
2005520230.tif 000026
2005520230.tif 000027
2005520230.tif 000028
2005520230.tif 000029