(57)【要約】少なくとも１つの信頼ソースをシステム内に設けるステップと、レポートを定期的に発行するために上記信頼ソースを定期的に作動するステップと、各信頼ソースのレポートをセキュリティ補正ユニットにインポートし、すべての上記のレポートからの詳細を含む１つの統合ファイルを作成するステップと、セキュリティ補正ユニットにすべてのセキュリティパッケージの属性ファイルをインポートするステップと、統合ファイルの内容をインポートされた属性ファイルの各々と個別に比較し、統合ファイル内に含まれるセキュリティ情報によって各属性ファイルを更新し、属性ファイルから欠けている情報を属性ファイルに関連付けるステップと、更新された属性ファイルに個別にエクスポートし、前記属性ファイルの各々を対応するセキュリティパッケージの属性ファイルとして活性化し、その結果、セキュリティポリシーを更新するステップと、を含む方法。
2005530223.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのセキュリティパッケージによって保護されるコンピュータシステム内でセキュリティポリシーを作成および／または更新する方法であって、
ａ．前記システム内に少なくとも１つの信頼ソースを設け、前記システムの構造および／または属性および／または前記システム内のセキュリティの欠点を列挙するセキュリティレポートを発行することができるステップと、
ｂ．前記レポートを定期的に発行するために、前記少なくとも１つの信頼ソースを定期的に作動するステップと、
ｃ．各信頼ソースのレポートをセキュリティ補正ユニットにインポートして、すべての前記レポートからの詳細を含む１つの統合ファイルを作成するステップと、
ｄ．前記セキュリティ補正ユニットにすべてのセキュリティパッケージの属性ファイルをインポートするステップと、
ｅ．前記統合ファイルの内容と前記インポートされた属性ファイルの各々を個別に比較し、前記統合ファイル内に含まれる前記セキュリティ情報によって各属性ファイルを更新し、前記属性ファイルから欠けている情報を前記属性ファイルと関連付けるステップと、
ｆ．前記更新された属性ファイルを個別にエクスポートし、前記属性ファイルの各々を対応するセキュリティパッケージの属性ファイルとして活性化し、その結果、セキュリティポリシーを更新するステップと、を含む方法。
【請求項２】
ａ．各信頼ソースのレポートをインポートするステップが各レポートを共通のフォーマットに変換し、前記共通のフォーマットで前記統合ファイルを作成するステップをさらに含み、
ｂ．すべてのセキュリティパッケージの前記属性ファイルを前記セキュリティ補正ユニットにインポートするステップが、各属性ファイルを前記共通のフォーマットに変換するステップをさらに含み、
ｃ．前記更新された属性ファイルを個別にエクスポートし、前記属性ファイルを対応するセキュリティパッケージの属性ファイルとして活性化するステップが、前記エクスポートするステップの前に、共通のフォーマットからの前記属性ファイルをパッケージ特定のフォーマットに変換するステップをさらに含む請求項１に記載の方法。
【請求項３】
前記更新するステップは、いずれかを更新して有効とし、いずれかを無視するかを決定するために、さらに所定の一連の論理規則を用いることによって行われる請求項１に記載の方法。
【請求項４】
前記レポートの各々は、少なくとも１つの属性コンポーネントを含む請求項１に記載の方法。
【請求項５】
前記発行されたレポートの各々は、対応する信頼ソース特定のフォーマットに整えられる請求項２に記載の方法。
【請求項６】
前記属性ファイルの各々は、対応するパッケージ特定のフォーマットに整えられる請求項２に記載の方法。
【請求項７】
各セキュリティパッケージは、その属性ファイルの内容に応じて、その所定の責任範囲内でセキュリティポリシーに作用する請求項１に記載の方法。
【請求項８】
１つ以上の信頼ソースは、セキュリティスキャナである請求項１に記載の方法。
【請求項９】
更新する際に含まれる一部またはすべてのステップは、オペレータの承認を必要とする半自動的な方法で実行される請求項１に記載の方法。
【請求項１０】
前記信頼ソースの一部は、手動でレポートを発行する人間である請求項１に記載の方法。
【請求項１１】
前記レポートに含まれる前記属性コンポーネントの一部は、既知の欠点の問題点を除去することを目的とする属性であり、前記属性コンポーネントの一部は予測不能な問題点を除去することを目的とする属性である請求項１に記載の方法。
【請求項１２】
予測不能な問題点を除去することを目的とする前記レポートに含まれる前記属性は、前記システムの現在の構造に関連する属性であり、更新された属性ファイル内に記録されるとき、前記構造に制限されるセキュリティポリシーを強化し、前記構造から逸脱する働きを却下する属性である請求項１１に記載の方法。
【請求項１３】
セキュリティポリシーを作成および／または更新するシステムであり、
ａ．所定の責任範囲内でセキュリティポリシーを強化する少なくとも１つのセキュリティパッケージであって、前記ポリシーが前記パッケージの各々に関連する特定の属性ファイルによって定義されるセキュリティパッケージと、
ｂ．前記システムの構造および／または属性および／または前記システム内のセキュリティの欠点を列挙するセキュリティレポートを発行することができる少なくとも１つの信頼ソースと、
ｃ．セキュリティ補正ユニットであって、
‐すべての信頼ソースから前記レポートをインポートし、すべての前記レポートからの情報を含む統合ファイルを作成するため、および
‐すべてのセキュリティパッケージから前記属性ファイルをインポートし、前記統合ファイルの内容を前記インポートされた属性ファイルの各々と個別に比較し、各属性ファイルを前記統合ファイル内に含まれるセキュリティ情報によって更新し、前記属性ファイルから欠けている情報を前記属性ファイルに関連付け、前記更新された属性ファイルをエクスポートし、前記属性ファイルの各々を対応するセキュリティパッケージの属性ファイルとして活性化し、その結果、セキュリティポリシーを更新するためのセキュリティ補正ユニットと、を備えるシステム。
【請求項１４】
前記セキュリティ補正ユニットは、
‐各信頼ソースからのレポートをインポートするための少なくとも１つの第１のインポートモジュールと、
‐前記レポートの各々を受信し、すべての前記レポートに含まれる情報を含む１つの統合ファイルを作成するための統合モジュールと、
‐各セキュリティパッケージから前記補正ユニットにその対応する属性ファイルをインポートするための少なくとも１つの第２のインポートモジュールと、
‐前記統合ファイルの内容を前記インポートされた属性ファイルの各々と比較し、各属性ファイルを前記統合ファイル内に含まれる前記セキュリティ情報によって更新し、前記属性ファイルから欠けている情報を前記属性ファイルに関連付けるためのセキュリティポリシー作成モジュールと、
‐各更新された属性ファイルをその対応するセキュリティパッケージにエクスポートし、その結果、セキュリティポリシーを更新するための少なくとも１つのエクスポートモジュールと、を備える請求項１３に記載のシステム。
【請求項１５】
各レポートをその信頼ソース特定のフォーマットから共通のフォーマットに変換するための少なくとも１つの第１の変換モジュールと、各インポートされた属性のセキュリティパッケージをそのパッケージ特定のフォーマットから共通のフォーマットに変換するための少なくとも１つの第２の変換モジュールと、対応するパッケージにエクスポートする前に、各更新された属性ファイルを共通のフォーマットからそのパッケージ特定のフォーマットに変換するための少なくとも１つの第３の変換モジュールと、をさらに備え、前記統合ファイルもまた前記共通のフォーマットに整えられる請求項１４に記載のシステム。
【請求項１６】
前記セキュリティポリシー作成モジュールはさらに、前記属性ファイルを更新中に用いるための一連の所定の論理決定規則をさらに含む請求項１４に記載のシステム。
【請求項１７】
前記セキュリティパッケージの１つは侵入検出システムであり、その一連のシグネチャがファイル内に格納され、前記ファイルがセキュリティパッケージの前記属性ファイルとして処理され、その結果、それに応じて更新される請求項１３に記載のシステム。
【請求項１８】
前記セキュリティパッケージの１つはアプリケーションスイッチであり、方向付けのために用いられるその一連の属性がファイル内に格納され、前記ファイルがセキュリティパッケージの属性ファイルとして前記システムによって処理され、その結果、それに応じて更新される請求項１３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータアプリケーション、ネットワークおよびサービスを保護する分野に関する。さらに詳細には、本発明は、セキュリティポリシーの設定を簡素化し、アプリケーション、ネットワークまたはアプリケーションが提供するサービスの中で、セキュリティ効果を有する変更の導入時にセキュリティポリシーを動的に修正するための方法およびシステムに関する。本発明の最も好ましい実施形態において、上記の第１の設定および設定に対する修正は、自動的な方式で実行される。あるいは、半自動方法または手動方法もまた、本発明の範囲内にある。
【背景技術】
【０００２】
接続性、機能性およびセキュリティは、組織のアプリケーション環境における目的と相反している。コンピュータアプリケーションの一般的な現在の実装により、ユーザは、現在の組織の必要条件を満たすため、広範囲のアプリケーションを実行することができ、種々のサービスを提供することができる。残念なことに、多くのユーザに広範囲のアプリケーションサービスを提供する必要条件により、これらのサービスがハッカーまたは無許可の実体などの外部実体によって攻撃または悪用される可能性がある。
【０００３】
現在、セキュリティに配慮したコンピュータアプリケーションおよびサービスは、「最優良事例（ベストプラクティス）」のガイドラインと、アプリケーションまたはサービスおよび関連するネットワークに関する予備的知識と、に基づくセキュリティポリシーの手動設定を必要としている。セキュリティポリシーを強化し、認められていない欠点、使用または動作を検出する機能をシステム管理者に提供するために、専用のセキュリティアプリケーションが開発されている。セキュリティアプリケーションの中には、ネットワークドメインの中でセキュリティを強化する意図を持ったネットワーク指向のものがある。そのようなネットワーク指向のセキュリティアプリケーションの例としては、チェックポイント・インコーポレイテッド（Ｃｈｅｃｋｐｏｉｎｔ  Ｉｎｃ．）およびシマンテック・インコーポレイテッド（Ｓｙｍａｎｔｅｃ  Ｉｎｃ．）による「ファイアウォール」が挙げられる。また、アプリケーションドメイン内のセキュリティポリシーを強化し、保証するためのアプリケーション指向のセキュリティパッケージも導入されている。そのようなアプリケーションドメインセキュリティパッケージの例は、カバドゥ・インコーポレイテッド（ＫａＶａＤｏ  Ｉｎｃ．）による「インタードゥ（ＩｎｔｅｒＤｏ）」である。通常は、適用されるセキュリティポリシーは、管理者のセキュリティスキル、アプリケーション、ネットワーク、サービスおよび全体的な環境の知識に大きく左右され、影響される。
【０００４】
以下「セキュリティスキャナ」と呼び、より一般的には「信頼ソース」と呼ぶ手段もまた、当業界では周知であり、コンピュータ環境が集合としてセキュリティポリシーに準拠しているかどうか検査するために用いられる。このようなスキャナまたは信頼ソースの各々は一般に、１つのセキュリティパッケージと互換性がある。スキャナは、セキュリティアプリケーションによって保護されるドメインをテストして厳密に調査し、発見された欠点および識別された属性に関するレポートを提供する。その後、管理者は依然としてレポートを翻訳し、必要なものをすべて補正する。レポートされた欠点および識別された属性の補正は、システム管理者のスキルに大きく左右される。さらに詳細には、多数回の補正には、平均的なシステム管理者には欠けているプログラミング指向のスキルが必要である。
【０００５】
この問題の別の態様は、コンピュータ環境がきわめて動的であるという事実である。新規ユーザが環境に導入され、他のユーザが削除され、新たなアプリケーションまたはハードウェアが導入または排除され、最も重要なことはアプリケーション自体が多くの場合には環境の中でプログラマまたはユーザによって動的に修正または変更されることである。システム管理者がこのように急速に発生する変更のすべてを完全に制御していないことが多く、仮に制御していたとしてもその多くは後でレポートされる。上述の状況の結果として、現在のセキュリティポリシーはどちらかと言えば静的に強化され、アプリケーションおよび環境は依然として無防備なままである。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、互換性のないセキュリティの欠点および属性を検査して確認し、上記の欠点を自動的または半自動的に補正または排除するために、強化されるセキュリティポリシーに対するアプリケーションおよびその環境の準拠を常にまたは定期的に検査するためのシステムおよび方法を提供することにある。
【０００７】
本発明の別の目的は、コンピュータ環境の中で作動するセキュリティアプリケーションを上記のシステムおよび方法と関連付けることにある。
【０００８】
本発明のさらに別の目的は、コンピュータ環境の中で作動する任意のセキュリティアプリケーションによって強化される各々の特定のセキュリティポリシーを動的に検査および補正するための手段を提供することにある。
【０００９】
本発明のさらに別の目的は、上記のタスクを簡素かつ効率的な方式で提供することにある。
【００１０】
本発明のさらに別の目的は、セキュリティスキャナまたは他の信頼ソースから欠点の表示およびレポートを効率的に受信し、自動的または半自動的な方式で、欠点を補正すことができる手段を提供することにある。
【００１１】
本発明の他の目的および利点は、以下の詳細から明白となるであろう。
【課題を解決するための手段】
【００１２】
本発明は、少なくとも１つのセキュリティパッケージによって保護されるコンピュータシステム内でセキュリティポリシーを更新する方法であって、ａ．システム内に少なくとも１つの信頼ソースを設け、システムの構造またはシステム内のセキュリティの欠点を列挙するセキュリティレポートを発行することができるステップと、ｂ．上記のレポートを定期的に発行するために、上記の少なくとも１つの信頼ソースを定期的に作動するステップと、ｃ．各信頼ソースのレポートをセキュリティ補正ユニットにインポートして、すべての上記のレポートからの詳細を含む１つの統合ファイルを作成するステップと、ｄ．前記セキュリティ補正ユニットにすべてのセキュリティパッケージの属性ファイルをインポートするステップと、ｅ．前記統合ファイルの内容とインポートされた属性ファイルの各々を個別に比較し、前記統合ファイル内に含まれるセキュリティ情報によって各属性ファイルを更新し、上記の属性ファイルから欠けている情報を上記の属性ファイルと関連付けるステップと、ｆ．上記の更新された属性ファイルを個別にエクスポートし、属性ファイルの各々を対応するセキュリティパッケージの属性ファイルとして活性化し、その結果、セキュリティポリシーを更新するステップと、を含む方法に関する。
【００１３】
この方法は、ａ．各信頼ソースのレポートをインポートするステップが各レポートを共通のフォーマットに変換するステップをさらに含むステップと、ｂ．すべてのセキュリティパッケージの属性ファイルを上記のセキュリティ補正ユニットにインポートするステップが各属性ファイルを上記の共通のフォーマットに変換するステップをさらに含むステップと、ｃ．上記の更新された属性ファイルを個別にエクスポートし、属性ファイルを対応するセキュリティパッケージの属性ファイルとして活性化するステップが、上記のエクスポートステップの前に、共通のフォーマットからの上記の属性ファイルをパッケージ特定のフォーマットに変換するステップをさらに含むステップと、をさらに含むことが好ましい。
【００１４】
上記の更新ステップは、いずれかを更新して有効とし、いずれかを無視するかを決定するために、さらに所定の一連の論理規則を用いて行われることが好ましい。
【００１５】
上記のレポートの各々は、少なくとも１つの属性コンポーネントを含むことが好ましい。
【００１６】
上記の発行されたレポートの各々は、対応する信頼ソース特定のフォーマットに整えられることが好ましい。
【００１７】
上記の属性ファイルの各々は、対応するパッケージ特定のフォーマットに整えられることが好ましい。
【００１８】
各セキュリティパッケージは、その属性ファイルの内容に応じて、その所定の責任範囲内でセキュリティポリシーに作用することが好ましい。
【００１９】
本発明の実施形態において、１つ以上の信頼ソースは、セキュリティスキャナであってもよい。
【００２０】
本発明の一実施形態において、更新する際に含まれる一部またはすべてのステップは、オペレータの承認を必要とする半自動的な方法で実行される。
【００２１】
本発明の実施形態において、信頼ソースの一部は、手動でレポートを発行する人間であってもよい。
【００２２】
本発明の一実施形態において、レポートに含まれる属性コンポーネントの一部は既知の欠点の問題点を除去することを目的とする属性であり、上記属性コンポーネントの一部は予測不能な問題点を除去することを目的とする属性である。
【００２３】
予測不能な問題点を除去することを目的とするレポートに含まれる属性は、システムの現在の構造に関連する属性であり、更新された属性ファイル内に記録されるとき、上記の構造に制限されるセキュリティポリシーを強化し、上記の構造から逸脱する働きを却下する属性であることが好ましい。
【００２４】
本発明はさらに、セキュリティポリシーを更新するシステムであり、ａ．所定の責任範囲内でセキュリティポリシーを強化する少なくとも１つのセキュリティパッケージであって、上記のポリシーが上記のパッケージの各々に関連する特定の属性ファイルによって定義されるセキュリティパッケージと、ｂ．システムの構造またはシステム内のセキュリティの欠点を列挙するセキュリティレポートを発行することができる少なくとも１つの信頼ソースと、ｃ．１．すべての信頼ソースから上記のレポートをインポートし、すべての上記のレポートからの情報を含む統合ファイルを作成するため、および２．すべてのセキュリティパッケージから属性ファイルをインポートし、上記の統合ファイルの内容をインポートされた属性ファイルの各々と個別に比較し、各属性ファイルを上記の統合ファイル内に含まれるセキュリティ情報によって更新し、上記の属性ファイルから欠けている情報を上記の属性ファイルに関連付け、上記の更新された属性ファイルをエクスポートし、属性ファイルの各々を対応するセキュリティパッケージの属性ファイルとして活性化し、その結果、セキュリティポリシーを更新するためのセキュリティ補正ユニットと、を備えるシステムに関する。
【００２５】
セキュリティ補正ユニットは、ａ．各信頼ソースからのレポートをインポートするための少なくとも１つの第１のインポートモジュールと、ｂ．上記のレポートの各々を受信し、すべての上記のレポートに含まれる情報を含む１つの統合ファイルを作成するための統合モジュールと、ｃ．各セキュリティパッケージから補正ユニットにその対応する属性ファイルをインポートするための少なくとも１つの第２のインポートモジュールと、ｄ．上記の統合ファイルの内容をインポートされた属性ファイルの各々と比較し、各属性ファイルを上記の統合ファイル内に含まれるセキュリティ情報によって更新し、上記の属性ファイルから欠けている情報を上記の属性ファイルに関連付けるためのセキュリティポリシー作成モジュールと、ｅ．各更新された属性ファイルをその対応するセキュリティパッケージにエクスポートし、その結果、セキュリティポリシーを更新するための少なくとも１つのエクスポートモジュールと、を備えることが好ましい。
【００２６】
本発明の実施形態において、システムはさらに、各レポートをその信頼ソース特定のフォーマットから共通のフォーマットに変換するための少なくとも１つの第１の変換モジュールと、各インポートされた属性のセキュリティパッケージをそのパッケージ特定のフォーマットから共通のフォーマットに変換するための少なくとも１つの第２の変換モジュールと、対応するパッケージにエクスポートする前に、各更新された属性ファイルを共通のフォーマットからそのパッケージ特定のフォーマットに変換するための少なくとも１つの第３の変換モジュールと、を備え、統合ファイルもまた上記の共通のフォーマットに整えられる。
【００２７】
本発明の実施形態において、セキュリティポリシー作成モジュールはさらに、属性ファイルを更新中に用いるための一連の所定の論理決定規則を含んでもよい。
【００２８】
本発明のさらに別の実施形態において、セキュリティパッケージの１つは侵入検出システムまたは侵入防御システムであり、その一連のシグネチャがファイル内に格納され、上記のファイルがセキュリティパッケージの属性ファイルとして処理され、その結果、それに応じて更新される。
【００２９】
本発明のさらに別の実施形態において、セキュリティパッケージの１つはアプリケーションスイッチであり、方向付けのために用いられるその一連の属性がファイル内に格納され、上記のファイルがセキュリティパッケージの属性ファイルとしてシステムによって処理され、その結果、それに応じて更新される。
【発明を実施するための最良の形態】
【００３０】
図１は、従来技術によるサービスを複数のユーザに提供するアプリケーション環境を保護するための代表的なセキュリティシステムを示している。アプリケーション１は、サービスを複数のユーザＵＳＥＲ１〜ＵＳＥＲｎに提供する。アプリケーションを適正に作動するための権利、さらに詳細には、ネットワーク内の活動がネットワークセキュリティパッケージ６によって保護されている。ネットワークセキュリティパッケージは、たとえば、チェックポイント・インコーポレイテッド（Ｃｈｅｃｋｐｏｉｎｔ  Ｉｎｃ．）によって配布されているような「ファイアウォール」パッケージであってもよい。アプリケーション自体の中で特定の特性を作動するための権利、たとえば特定のサービスを受信するための権利は、カバドゥ・インコーポレイテッド（ＫａＶａＤｏ  Ｉｎｃ．）によって配布される「インタードゥ（ＩｎｔｅｒＤｏ）」などのアプリケーションセキュリティパッケージ２によって保護されている。さらに多くのアプリケーション、セキュリティパッケージおよびユーザが保護される環境に存在する可能性があるが、これらは簡潔にするためにこの図には示されていない。一般に、各セキュリティパッケージは、その定義された責任範囲内（アプリケーション、ネットワークまたはその両方）でシステム管理者によって定義されるセキュリティポリシーを強化し管理する。各パッケージのセキュリティポリシーは、一般にそのパッケージに専用の属性ファイルに保存される属性によって表現される一連の異なる制約を含む。図１において、アプリケーションセキュリティパッケージの属性ファイルは符号３によって示され、ネットワークセキュリティパッケージの属性ファイルは符号７によって示される。さらに、アプリケーションまたはネットワーク内のセキュリティの欠点を検査するためのプログラムが開発されている。そのようなプログラムは一般にスキャナと呼ばれ、本願明細書では「セキュリティスキャナ」と呼ばれている。特定のパッケージと同一のメーカによって提供され得るセキュリティスキャナは一般に、各パッケージにそれぞれ特定であり、その目的はパッケージの責任範囲であるネットワーク、アプリケーションまたはその両方をテストし、適正に処理される必要がある検出された欠点に関する属性を含むレポートをシステム管理者に提供することである。スキャナは一般に、ネットワークおよび／またはアプリケーションの種々の態様を厳密に調べることによって動作する。このレポートを得たシステム管理者は一般に、対応する属性ファイルに対する修正を導入しなければならない。これは一般に複雑な手順であり、多くの場合には、平均的なシステム管理者のスキルを超えるタスクの実行を必要とする。さらに、動的であり、任意の瞬間に変化する可能性があるシステムの脆弱性は、システム管理者がスキャナテストを実行する頻度に左右され、これらを高い繰り返し率で実行することができない。
【００３１】
図２は、本発明の一実施形態による改良したセキュリティシステムの構造を示している。本発明によれば、セキュリティ補正ユニット１０が設けられる。セキュリティアプリケーションスキャナ４およびネットワークスキャナ８は、従来どおり動作を実行する。レポートの各々の内容もまた、セキュリティ補正ユニット１０にインポートされる。セキュリティ補正ユニットはまた、既存の属性ファイルの各々をインポートする（１５、１６）。セキュリティ補正ユニットは、アプリケーションスキャナおよび／またはネットワークスキャナから受信した欠点の属性（１７、１８）を分析して、その属性を対応する既存の属性ファイル３および７の各々と比較し、必要な場合に限り、属性に対する修正を発行し、新たな補正された属性ファイルまたは既存の属性ファイル３および７に対する修正のみのいずれかを出力する。更新された属性ファイルは、検出された欠点を除去するために必要な補正を含む。スキャナレポートに加えて、他の信頼ソース２０、すなわち信頼できる欠点レポートおよび属性レポートを提供することができると考えられるソースからセキュリティ補正ユニットに欠点レポートが提供されてもよいことにさらに留意すべきである。さらに、本発明の最も好ましい実施形態では、改良システムの動作は全自動方式で実行されるが、一部の実施形態では動作は半自動、手動またはそれらの組合せであってもよい。
【００３２】
当業界では周知かつ一般的であるように、各属性ファイルは、その特定の構造を有し、特定の属性を処理する。以下に、様々な属性ファイルに対する更新を行うことができるようにするために、セキュリティ補正ユニット１０がこの欠点をどのようにして克服するかを示す。
【００３３】
図３は、セキュリティ補正ユニット１０の動作をさらに詳細に示すブロック図である。セキュリティ補正ユニットは、特にネットワークスキャナ４およびアプリケーションスキャナ８から欠点属性レポートをインポートするが、他の信頼ソース２０からレポートまたは部分的な欠点の指摘を受信してもよい。レポートはまた、システムのツリーマップなどの検査されるシステムの現在の一般的な構造に関する情報を含んでもよい。レポートの各々は一般に、そのパッケージ特定のフォーマットの形式があり、フォーマットは互いに異なるため、特定の欠点レポートの各々は、各々変換ステージ２１、２２および２３によって補正ユニット１０に特定される同一の共通のフォーマットに変換される。変換ステージ２３、２４および２５からの欠点の出力は上記の共通のフォーマットでなされ、上記の共通のフォーマットにおいてすべての欠点レポートを１つのファイルに統合する統合ユニット４０に伝達される。セキュリティ補正ユニットはさらに、セキュリティパッケージからそれらの属性ファイルをインポートする。簡潔にするため、図３にはターゲットパッケージ３２の１つのみが示されているが、当業者には明白であるように、補正ユニットは、たとえばネットワークセキュリティパッケージ６およびアプリケーションセキュリティパッケージ２などの複数のセキュリティパッケージのセキュリティポリシーを本願明細書に示されたものと同一の方式で補正してもよく、実際補正する。セキュリティ補正ユニットは、対応するセキュリティパッケージから属性ファイル３または７をインポートし、次にユニット２７によってそれを上記の共通のフォーマットに変換する。結果として生じる変換された属性ファイルは、上記の共通のフォーマットであり、セキュリティポリシー作成モジュール２８に個別に伝達される。続いて、セキュリティポリシー作成モジュール２８は、上記のように複数のソース（セキュリティスキャナを含む）から欠点レポートを受信し、セキュリティパッケージから現在の属性ファイルを受信して、上記の共通のフォーマットで１つの大きな属性ファイルを作成する。上記の１つの大きな属性ファイルは、すべての複数のインポートされた属性ファイル（現在のセキュリティポリシーを反映する）から合わせたすべての属性に加えて、セキュリティスキャナを含む信頼ソースから受信されたすべての欠点属性を含み、欠点を除去するために追加されるべき欠点属性を反映している。さらに詳細には、セキュリティポリシー作成モジュール２８によって作成された大きな共通ファイルは、システムに存在するすべてのセキュリティパッケージによって強化される必要があるすべての制約を反映している。続いて、変換ユニット２９が、上記の大きな共通ファイルを各セキュリティパッケージ用に、各パッケージに特定されるフォーマットに変換する。当然のことながら、この変換は、ターゲットパッケージ３２の特定の属性ファイルとは無関係の大きな共通ファイルに存在するいくつかの制約の排除を伴う。たとえば、大きな共通ファイルは、アプリケーションセキュリティパッケージの属性ファイルとは無関係のネットワーク属性を含んでもよく、これらの属性は変換手順２９の中で排除される。別の実施例において、ネットワークセキュリティパッケージ６のためのフォーマット変換２９を行う際に、ネットワークセキュリティパッケージとは無関係のアプリケーション特定の属性が排除される。変換２９後に作成されるファイルは更新された属性ファイルであり、次に、対応するセキュリティパッケージの属性ファイルとしてエクスポートされ保存される。更新されるファイルに問題が発見された場合、または更新されるファイルの方が好ましくないことが分かった場合に、元に戻すことができるようにするために、「古い」以前の属性ファイルが最初に保存され、次に更新されるファイルによって置換されることが好ましい。
【００３４】
本発明の一実施形態において、セキュリティポリシー作成モジュール２８の動作は、特定の問題に直面した場合にモジュールがどのように作動するかを定義する一連の論理規則に準拠するまたは関連するとしてもよいことに留意すべきである。たとえば、一連の論理規則は、信頼ソースによって特定の属性がレポートされるときに、新たな更新されたポリシーに適用され、作用するかどうかを左右してもよい。このような一連の論理規則の存在は、本発明の範囲内にあり、図３において２８ａとして表記される。
【００３５】
任意のセキュリティシステムは、２つのアプローチ、すなわち肯定的アプローチ、否定的アプローチまたはその組合せのうちの１つで動作してもよい。
ａ．否定的アプローチ：アプリケーションの中で許容されるべきではない任意のタイプの動作またはアクセスに関連する一連の「否定的」属性が定義され、属性ファイル内に保存される。アプリケーションの中ですべての要求される動作またはアクセスは、上記の一連の属性に対してセキュリティシステムによって連続的に照合される。要求される動作（またはアクセス）が一連の属性の１つに適合することが発見された場合には、不正であると関連付けられ、拒否される。否定的アプローチで動作するセキュリティシステムの実施例は、アンチウイルスシステムである。このアプローチの欠点は、（たとえばウイルスなどの不正な状況に以前に直面した）他の信頼ソースから学習した状況によってセキュリティシステムは連続的に更新される必要があり、またはシステム管理者が、将来起こり得る不正動作（生じる前に）を予測し、それに応じて属性を属性ファイルに追加する必要があることである。
ｂ．肯定的アプローチ：アプリケーションの中で許容されるすべての正当な動作またはアクセスがシステム管理者によって定義され、対応する一連の「肯定的な」属性が属性ファイル内に保存される。保存された一連の属性の１つに適合しない任意の動作またはアクセスは、不正であると見なされ、拒否される。このアプローチの利点は、システム管理者が将来の不正状況を予測しなくてもよいことである。そのような状況（一連の属性の１つを満たさない）は、デフォルトで不正と見なされるためである。したがって、このシステムは、より安全である。しかし、このアプローチの欠点は、保存された一連の属性の１つによって前もって反映されていない場合に、本質的に正当な状況が拒否される恐れがある。したがって、このアプローチは、頻繁に修正されるシステムには好ましくない。
【００３６】
本発明は、上記の否定的または肯定的アプローチの一方を適用するセキュリティシステムまたは上記の２つのアプローチを結合するシステムによって作動してもよい。したがって、本願を通じて、属性ファイルは、上記の否定的または肯定的アプローチまたはその組合せのいずれかに関連する属性を含んでもよい。
【００３７】
以下は、信頼ソースから提供されることができ、作成される共通ファイル内に含まれてもよい属性タイプに関するいくつかの例である。
１．ネットワーク属性―たとえば、ネットワークプロトコル名およびバージョン、ポート）―共通ソース：ネットワークセキュリティスキャナ、ルータ、ファイアウォールパッケージ、スイッチ、ネットワークスニファなど。
２．アプリケーション属性―たとえば、アプリケーションプロトコル名およびバージョン、ドメイン、適用方法。共通ソース：ファイアウォールパッケージ、ネットワークセキュリティスキャナ、アプリケーションセキュリティスキャナ、ウェブサーバ、侵入検出システムなど。
３．アプリケーションパス属性―たとえば、ページ位置、仮想ディレクトリ名など。共通ソース：アプリケーションスキャナ、ウェブサーバ、侵入検出システムなど。
４．アプリケーション動作属性―たとえば、サポート方法（たとえば、ＧＥＴ、ＳＥＴ、ＤＥＬＥＴＥ、ＰＯＳＴ）など。共通ソース：アプリケーションスキャナ、ウェブサーバ、ウェブアプリケーション、データベース、動作属性のデータ構造を詳述するＸＭＬスキーマ。
５．動作フロー属性―たとえば、動作の順番、ビジネスフローおよび論理。共通ソース：アプリケーションスキャナ、ウェブアプリケーション、データベース。
【００３８】
本発明のシステムは、以下のような２つのタイプの状況に直面する可能性があることを留意すべきである。
Ａ．既知の（予測される）問題点
１．アプリケーションの中で検出および／または照合される脆弱性に関して、信頼ソース（スキャナなど）が解決策を提供することができない。
２．検出および／または照合される脆弱性に関して、信頼ソースが解決策を示唆することができる。
Ｂ．未知の（予測不能な）問題点
適用詳細―本発明のシステムは、その動作中に既知または予測されない可能性がある脆弱な状況に直面する可能性がある。このような未知の状況に関してセキュリティを提供し、そのような将来の脆弱性を排除するために、別のセキュリティアプローチが必要となる。本発明によって適用されるアプローチは、「有効な」動作を、動作フロー、パス、属性（たとえばａｃｔｉｏｎ＝"ｌｏｇｉｎ．ｃｇｉ"、ｐａｔｈｓ＝"／ｄｅｍｏ"、ａｔｔｒｉｂｕｔｅｓ＝"ｕｓｅｒｎａｍｅ，ｐａｓｓｗｏｒｄ"）などの所定の属性を満たす一部だけに制限することである。上記の所定の属性に含まれない属性（たとえばａｃｔｉｏｎ＝"ｔｅｓｔ．ｃｇｉ"、ｐａｔｈｓ＝"／ｓａｍｐｌｅ"、ａｔｔｒｉｂｕｔｅｓ＝"ｄｅｂｕｇ"）によるアプリケーションへの任意のアクセスが、禁止される。このアプローチを用いて、これらの所定の属性を満たさない場合には、将来の脆弱性が排除される。（たとえばユーザが、ａｃｔｉｏｎとして"ｒｅｇｉｓｔｅｒ．ｃｇｉ"を要求した場合には、この動作は正当ではなく、この動作は正当な動作リストに含まれないため拒否される。）
【００３９】
したがって、本発明のシステムは、周知の問題点のみならず、未知の将来の脆弱性に対する解決策を含む更新されたセキュリティポリシーを提供するために、統合ファイルを用いる。解決策は、自動または半自動の方法で、オンラインで提供される。
【００４０】
図４は、たとえば、本発明の一実施形態による、アプリケーションセキュリティスキャナ４などの信頼ソースから本質的に属性のコンポーネントを含むファイルである欠点属性レポートをセキュリティ補正ユニット１０によってインポートし、同レポートを共通のフォーマットに変換する手順を示している。１つの「属性」がファイル内の複数行に広がってもよいことを本願明細書では留意すべきである。以下、１つの属性に関連するファイル内の行の群を「属性コンポーネント」と呼ぶ。ステップ６１において、補正ユニットは、選択されたデータソースに接続する。ステップ６２において、補正ユニットは、信頼ソースからのレポートを要求する。次に、ステップ６３において、補正ユニットは、スキャナ４からレポートをロードする。ステップ７０において、上記ユニットは、ロードされたレポートから第１の属性コンポーネントを読み出す。ステップ６４において、上記ユニットは、コンポーネントが共通のフォーマットであるかどうかを検査する。ステップ６４は、共通のフォーマットが信頼ソースの１つのフォーマットと同一であると予め定義される場合に限り、関連があるとしてもよいことに留意すべきである。共通のフォーマットがすべての信頼情報レポートのフォーマットのいずれとも異なっていると定義される場合には、ステップ６４は不必要であり、手順は自動的にフォーマットステップ６５に続く。ステップ６４において属性コンポーネントが共通のフォーマットでないと分かった場合には、属性コンポーネントはステップ６５において共通のフォーマットに変換され、ステップ６９において、統合ファイルに格納される。次に、ステップ６７において、上記ユニットは、読み出すべきさらに多くの属性コンポーネントがあるかどうかを検査する。読み出すべきさらに多くの属性コンポーネントがある場合には、手順はステップ６３に戻り、すべての属性コンポーネントを最終的に変換するまで繰り返す。すべての属性コンポーネントが読み出され、変換されると、手順は終了する（ステップ６９）。この手順の終了時に、統合ファイルが作成される。
【００４１】
図４の手順は、同一の統合ファイルに追加するように動作しながら、すべての該当する信頼ソースに関して繰り返す。
【００４２】
図５は、活性化した、変換ステージ２１，２２または２３（図３）のいずれかによって行われる図４の変換ステップ６５の動作を示している。ステップ８１において、ステージ６５は、入力レポートファイルのスキーマをロードして利用可能にする。「スキーマ」なる語は、本願明細書では、ファイル中のデータが編成される構造またはパターンを示すデータに関連する。ステップ８２において、ステージ６５は、共通の属性ファイルのスキーマをロードする。属性ファイルから読み出すデータの意味を決定し、共通ファイルのスキーマに基づいて、読み出されたデータを変換するために、ステップ６５には、２つのスキーマが必要である。ステップ８３において、当該ステージは、レポートファイルから１つの属性コンポーネントを、当然のことながらレポートファイルのフォーマット（入力フォーマット）で入力する（矢印８４）。次に、入力コンポーネントのフォーマットがレポートファイルの入力スキーマのフォーマットに適合するかどうかを検査する。適合しない場合には、変換が不可能であることを意味している。その場合には、ステップ９０において、手順は、処理を終了し、そのソースからのレポートファイル全体を無視するか、またはその入力されたコンポーネントのみを無視して、ステップ８３に戻って、レポートファイルから次のコンポーネントを検索するかを決定する（ステップ９０）。ステップ８７において、変換が可能であると仮定すると、コンポーネントは、共通の出力ファイルのスキーマに基づいて変換され、共通の（統合）ファイル内に属性コンポーネントとして保存される。ステップ８８において、当該ステージは、変換すべきさらに多くのコンポーネントがあるかどうかを検査する。変換すべきさらに多くのコンポーネントがある場合には、手順はステップ８４に戻る。これが最後の属性コンポーネントである場合には、手順は終了する（ステップ８９）。上述した本発明の一実施形態において、図５の手順は、種々の信頼ソースのすべてのレポートファイルに関して繰り返し、同一の統合ファイルにそれぞれ実行結果を追加する。図５の変換手順（図３のステージ２１、２２または２３）の複数の実行の結果が、共通の（統合）ファイルである。
【００４３】
本発明の別の実施形態において、図５の手順の各実行により、１つの一時変換ファイルが作成される。したがって、その手順の複数の実行を終了すると、図６の手順に進む。
【００４４】
図６のステップ１００において、処理は、新規統合ファイルのスケルトンを作成する。さらに詳細には、このスケルトンファイルは本質的に空の表であって、複数の一時ファイルからの属性が格納されるようになっている。ステップ１０１において、処理は、図５の手順によって作成される複数の一時変換ファイルを取得し、その有効性を確認する。ステップ１０２において、手順は、第１の一時ファイルから第１のコンポーネントを読み出し、スケルトン統合ファイル内の対応する空の属性空間を満たすことによって統合ファイルを更新することを始める（ステップ１０４）。ステップ１０７において、手順は、これが一時ファイルにおける最後のコンポーネントであるかどうかを検査する。該当しない場合には、手順は、次のコンポーネントに進み（ステップ１１０）、ステップ１０２に戻る。しかし、ステップ１０７において最後のコンポーネントに達したことが分かった場合には、手順は、ステップ１０５において、処理すべきさらに多くの一時ファイルがあるかどうかを検査する。ない場合には、手順が終了する。しかし、依然として未処理のファイルがある場合に、手順は次のファイルを検索するステップ１０６に進み、ステップ１０２に戻る。上記のように、図６の手順の結果が統合ファイルである。
【００４５】
図７は、どのようにして属性ファイルが信頼ソースからインポートされ、上記の共通のフォーマットで対応する一時属性ファイルに変換されるかを示している。ステップ１８１において、手順は、該当する属性ファイルのスキーマ、すなわち入力スキーマをロードする。ステップ１８２において、手順は、共通ファイルのスキーマをロードする。属性ファイルから読み出すデータの意味を決定し、共通ファイルのスキーマに基づいて、読み出されたデータを変換可能にするために、手順には、２つのスキーマが必要である。ステップ１８４において、手順は、該当する属性ファイルからコンポーネントを（入力フォーマットで）入力する。ステップ１８３において、手順は、属性ファイルから１つの属性コンポーネントを、当然のことながら属性ファイルのフォーマット（入力フォーマット）で入力する（矢印１８４）。次に、入力コンポーネントのフォーマットが属性ファイルの入力スキーマのフォーマットに適合するかどうかを検査する。適合しない場合には、変換が不可能であることを意味している。その場合には、ステップ１９０において、手順は、処理を終了し（ステップ１８９）、その属性ファイルを補正する可能性を排除するか、またはその入力されたコンポーネントのみを無視して、ステップ１８３に戻って、属性ファイルから次のコンポーネントを検索するかを決定する。ステップ１８７において、変換が可能であると仮定すると、コンポーネントは、共通の出力ファイルのスキーマに基づいて変換され、対応する一時属性ファイル内に（上記の共通のフォーマットで）属性コンポーネントとして保存される。ステップ１８８において、手順は、変換すべきさらに多くのコンポーネントがあるかどうかを検査する。変換すべきさらに多くのコンポーネントがある場合には、手順は属性ファイルからもう１つのコンポーネントを検索するために、ステップ１８４に戻る。しかし、これが最後の属性コンポーネントである場合には、手順は終了する（ステップ１８９）。図７の手順は、セキュリティパッケージの属性ファイルの各々に関して一度ずつ、複数回実行される。上記の複数の実行の終了時には、システムに対してすべて上記の共通のフォーマットで複数の対応する一時属性ファイルが利用可能である。上記の一時属性ファイルの各々は本質的に、対応するパッケージによって強化される共通のセキュリティポリシーを反映するファイルであるが、上記の共通のフォーマットで表現される。
【００４６】
次に、一方には統合ファイルを有し、他方には複数の一時変換属性ファイルを有し、すべてが同一の共通のフォーマットにフォーマットされることにより、セキュリティポリシー作成ファイルは、上記の一時属性ファイル補正の各々における置換から始まるか、または上記の統合ファイル内に含まれるように更新する。当然のことながら、上記の補正は本質的に、信頼ソースによって累積され、種々のレポートに含まれる属性を補正する。手順は、第１の一時属性ファイルの更新から始まる。
【００４７】
属性が、統合ファイル内、個別の属性ファイル内、属性タイプに基づくセクションの一時属性ファイル内に編成されることが好ましい。たとえば、ファイルは、以下のセクション、すなわちネットワーク属性、アプリケーション属性、アプリケーションパスなどを含んでもよい。したがって、手順は統合ファイルの第１のセクションに進み、たとえば、ネットワーク属性がセクション内の第１のコンポーネントを検索し、次に、同一の属性コンポーネントが一時属性ファイルの中に存在するかどうかを比較するために、一時属性ファイル内の対応するセクションに進む。同一の属性コンポーネントが一時属性ファイルの中に存在することが分かった場合には、更新は必要ではない。しかし、比較によって検索されたコンポーネントが一時属性ファイルの中に存在しないことが分かった場合には、（自動モードで動作している間に）上記の該当するセクションの中のそのファイルに同コンポーネントを追加する。半自動モードの動作では、一時属性ファイルの中の属性コンポーネントを更新するかどうかの決定は、オペレータの注意を喚起してもよいことを留意すべきである。次に、手順は、第１の一時属性ファイルの修正が終了するまで統合ファイルの中のすべての属性コンポーネントに関して繰り返される。その点に関して、統合ファイルが１つ以上の一時属性ファイルに無関係である属性コンポーネントを含んでもよいことを本願明細書では言及されるべきである。たとえば、ネットワーク指向の属性は、アプリケーションセキュリティパッケージの属性ファイルの中では無関係であってもよい。さらに、完全な属性タイプセクションが属性ファイルから抜けていてもよい場合もある。他方、属性コンポーネントが２つ以上の個別の一時属性ファイルに関連していることが分かる場合もある。本発明によれば、上記のいずれの場合も妥当である。
【００４８】
上述したものと同一の更新手順が、すべての一時属性ファイルに関して繰り返される。次に、（各々が共通のフォーマットである）上記の一時属性ファイルの各々を対応する各セキュリティパッケージ特定のフォーマットに変換するために、後方変換手順が実行される。上記の後方変換は、上述の変換と類似の方法で実行される。図８は、どのようにして上記の後方変換が実行されるかを示している。ステップ２８１において、手順は、該当する一時属性ファイルのスキーマを、すなわち共通のフォーマットでロードする。ステップ２８２において、手順は、すなわちパッケージ特定のフォーマットで該当する属性ファイルの出力スキーマをロードする。属性ファイルから読み出すデータの意味を決定し、共通ファイルのスキーマに基づいて、読み出されたデータを変換可能にするために、手順には、２つのスキーマが必要である。ステップ２８４において、手順は、該当する一時属性ファイルから第１のコンポーネントを（入力フォーマットで）入力する。ステップ２８３において、手順は、一時属性ファイルから１つの属性コンポーネントを、当然のことながら一時属性ファイルのフォーマット（共通のフォーマット）で入力する（矢印２８４）。ステップ２８７において、コンポーネントが出力のスキーマに基づいてパッケージ特定のフォーマットに変換され、対応する属性ファイル内に（上記のパッケージ特定のフォーマットで）属性コンポーネントとして保存される。ステップ２８８において、手順は、変換すべきさらに多くのコンポーネントがあるかどうかを検査する。変換すべきさらに多くのコンポーネントがある場合には、手順は一時属性ファイルからもう１つのコンポーネントを検索するために、ステップ２８４に戻る。しかし、これが最後の属性コンポーネントである場合には、手順は終了する（ステップ２８９）。図８の手順は、一時属性ファイルの各々に関して一度ずつ、複数回実行される。上記の複数の実行の終了時には、システムに対してそのパッケージ特定のフォーマットで各セキュリティパッケージにつき１つの複数の対応する属性ファイルが利用可能である。上記の属性ファイルの各々は本質的に、その対応するセキュリティパッケージに関して更新されるセキュリティポリシーを含む。ファイルは、その宛て先のセキュリティパッケージに各々エクスポートされる。置換前に、オペレータは、属性ファイルの置換の確認を求められるようにしてもよい。
【００４９】
上記のように、セキュリティシステムは、以下のように対処すべき２つのタイプの問題点に直面する可能性がある。
ａ．「既知の」問題点、すなわち予測することができる問題点への対処
ｂ．「未知の」問題点、すなわち予測することができない将来の問題点への対処
【００５０】
スキャナなどの信頼ソースからのレポートは一般に、上記の２つの問題点の両方に対する解決策を提供することを目的としている。第１の問題点に関する実施例は、アクセスが禁止されるものとして定義されているにもかかわらず、システムにおいてアクセス可能な位置の１つ以上のパスを列挙するレポートである。そのようなレポートおよびそのような欠点が本発明のシステムによって除去される方法の詳細な実施例は、以下のように与えられる。
【００５１】
第２の（「未知の」）問題点に直面するための手段を提供することを目的としている信頼ソースからのレポートもまた、一般に提供される。そのようなレポートは、アプリケーション（またはネットワーク）の「マップ」、すなわち、すべてのアプリケーションの位置、それらの関連パスを示すツリーを含んでもよい。言い換えれば、そのようなツリーは、たとえば、アプリケーション内のすべてのＨＴＭＬページおよびそれらのアクセス方法（関連したパス）を表示してもよい。本発明の実施形態によれば、これらのパスは、上記の「第２のタイプのレポート」の中に含まれるとき、唯一の有効な位置またはパスとして補正ユニットによって定義される。そのようなレポートが本発明の補正ユニットで受信されるとき、その内容は（変換を含む上述の処理を実行した後で）該当する属性ファイルに伝達される。このことは、誰かがアプリケーション（またはネットワーク）内の位置にアクセスしようとした場合、または有効であると明確に定義されないパスを用いようとした場合には、そのアクセスは拒否されることを意味している。このタイプは、ユーザがアプリケーション（およびネットワーク）内の位置に不正にアクセスしようするほぼ無限の可能性を予測することが困難であることから、「未知の」問題点と呼ばれるが、有能なセキュリティシステムは、このような「直面する未知の」問題点にも直面し対処する必要がある。
【実施例】
【００５２】
実施例１：
図９ａは、セキュリティアプリケーションスキャナなどの１つの信頼ソースから入手したような２つの属性コンポーネントに関する実施例を示している。さらに詳細には、これは、スキャナ属性レポートである。
【００５３】
図９ｂは、そのパッケージのセキュリティポリシーを形成するパッケージ（たとえば、「ゲートウェイ」）特定の属性ファイルの実施例を示している。示されているように、このファイルは、その下部に以下のような４つの許容されるアプリケーションパスを含む：
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｔｅｓｔ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｓａｍｐｌｅｓ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｄｅｍｏ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｃｇｉ−ｂｉｎ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
【００５４】
図１０ａは、統合前における空の統合ファイルを示している。図示されているように、このファイルは、本質的にスケルトンファイルであり、値を満たすためのフィールドを含む。
【００５５】
図１０ｂは、図９ａのレポートを共通のフォーマットに変換し、統合ファイルのスケルトンによって統合した後の統合ファイルを示している。図示されているように、図９ａのレポートはアプリケーションセクションで図１０に示されている２つのコンポーネントのみを含み、唯一の信頼ソースがこの実施例では用いられているため、統合ファイルの大半は空のままである。
【００５６】
図１１は、共通のフォーマットの一時属性ファイルを示している。さらに詳細には、これは、共通のフォーマットに変換された図９ｂの属性ファイルの変換である。
【００５７】
図１２は、統合ファイルからの情報によって更新された後の図１１の一時属性ファイルを示している。
【００５８】
図１３は、本発明のシステムによって修正され、最終的に更新されたパッケージ特定の属性ファイルを示している。さらに詳細には、図１３のこの属性ファイルは本質的に、図１０の統合ファイルからの情報によって修正された対応する一時属性ファイルである。図示されているように、（図９ｂの）属性ファイルに元々含まれていた以下のＡｐｐｌｉｃａｔｉｏｎＰａｔｈ属性が除去された：
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｔｅｓｔ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｓａｍｐｌｅｓ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｃｇｉ−ｂｉｎ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
この実施例の処理のために残っている唯一の属性は、
<ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>／ｄｅｍｏ<／ＡｐｐｌｉｃａｔｉｏｎＰａｔｈ>
である。さらに詳細には、元々、ユーザが４つのパス位置へのエントリを許可されていたのに対して、今度はそのうち３つのエントリがスキャナからの欠点属性レポートによって禁止される。
【００５９】
種々のセキュリティパッケージおよび信頼ソース（スキャナなど）が、多くの場合に異なる事業体によって製作されているので、多くの場合にはセキュリティパッケージおよび信頼ソース（スキャナなど）が異なるファイル構造およびフォーマットを用いるという事実のために、共通のフォーマットへのレポートファイルの変換および各パッケージ特定のフォーマットへの後方変換が必要とされることを留意すべきである。変換により、１つの共通のフォーマットで必要な処理を実行することができる。しかし、すべての上記のファイルが１つの共通のフォーマットで与えられるかまたは構造化される場合もある。そのような場合には、変換モジュールおよび対応する変換動作は、不必要であり、システムが変換を行うことなく構造化され動作されてもよい。
【００６０】
本発明のシステムはまた、セキュリティポリシーの更新のほか、セキュリティポリシーの作成のために用いられてもよいことをさらに留意すべきである。１つ以上のパッケージ属性ファイルがシステムの動作前には空であるときにこの作成オプションを用いることができ、更新により本質的に、そのパッケージのための新たなセキュリティポリシーを作成する。
【００６１】
実施例２：
以下の実施例は、本発明がきわめて有利である現実のシナリオを示している。以下の環境を仮定する：
‐独立のプライベートネットワークセグメントが、インターネットなどのパブリックネットワークに接続される。
‐プライベートネットワーク内で実行中のアプリケーションが、今度は、インターネットのユーザに対してアクセス可能となる。このようなユーザは信頼できないユーザと考えられるため、プライベートネットワークは複数のセキュリティパッケージを用いて、このようなユーザによるアプリケーションの不当な使用または損傷を与える可能性がある使用を排除する。
【００６２】
使用中のセキュリティパッケージ：
プライベートネットワーク内のセキュリティパッケージは、必要なセキュリティを提供するために、出入りするパケットおよび数バイトのストリームを調べる装置およびコンピュータプログラムを含む。たとえば、プライベート環境は、以下のセキュリティパッケージを利用する：
ネットワーク層ファイアウォール―（チェックポイント（Ｃｈｅｃｋｐｏｉｎｔ）およびシマンテック（Ｓｙｍａｎｔｅｃ）などによって提供される）ネットワーク層セキュリティ問題に対処するため
アプリケーション層ファイアウォール―（カバドゥ・インコーポレイテッド（ＫａＶａＤｏ）、エンターセプト（Ｅｎｔｅｒｃｅｐｔ）などによって提供される）アプリケーション層セキュリティ問題に対処するため
認証サーバ―（ネッテグリティ（Ｎｅｔｅｇｒｉｔｙ）、ＲＳＡ、チェックポイント（Ｃｈｅｃｋｐｏｉｎｔ）によって提供される）ユーザ名およびパスワードなどの特定の属性に基いてリモートユーザを認証するため
ネットワークスキャナ―ネットワーク層内の脆弱性を査定し、ネットワーク層属性（たとえば、プロトコルタイプ、バージョンなど）の識別および／または照合を行うため
アプリケーションスキャナ―アプリケーション層内の脆弱性を査定し、アプリケーション層属性（たとえば、プロトコル、変数、動作など）の識別および／または照合を行うため
【００６３】
上記の環境の詳細を仮定すると、プライベートネットワークシステム管理者は、自動的な方法で、アプリケーション層ファイアウォールポリシーの検査、照合および更新を希望する。
【００６４】
本発明に基いて、管理者は、利用可能な複数の信頼ソースを有する：
ネットワーク層ファイアウォール―ネットワーク層セキュリティ属性を提供する
認証サーバデータベース―認証ユーザ属性（たとえば、ユーザ名およびパスワード）を提供する
ネットワークスキャナによる脆弱性および属性のレポート―ネットワーク層セキュリティ属性（たとえば、プロトコル名、バージョンなど）および既知の脆弱性を提供する
アプリケーションスキャナによる脆弱性および属性のレポート―アプリケーション層セキュリティ属性（たとえば許容可能な動作、動作フロー、動作属性など）を提供する
アプリケーションデータベース―アプリケーションの変数名および値を提供する
【００６５】
本発明によれば、管理者は、アプリケーション層ファイアウォールセキュリティサーバからの既存のセキュリティポリシーを使用してもよい。
【００６６】
本願明細書に記載された方法により、アプリケーション層ファイアウォールセキュリティポリシーに関して統合される信頼ソースデータをその属性ファイルによって反映されるように適用することによって、新しいセキュリティポリシーまたは更新されたセキュリティポリシーが、自動的に作成され、自動、半自動または手動の方法で用いるために、アプリケーション層ファイアウォールセキュリティサーバにエクスポートされることができる。
【００６７】
実施例３：
侵入検出システム（ＩＤＳ）は、当業界では周知のネットワークタイプのセキュリティシステムである。そのようなシステムはまた、「ホストベース侵入検出システムまたは侵入防御システム」と呼ばれることもある。代表的なＩＤＳシステムは、たとえば、エンターセプト・インコーポレイテッド（Ｅｎｔｅｒｃｅｐｔ  Ｉｎｃ．）およびウェブコホート・インコーポレイテッド（ＷｅｂＣｏｈｏｒｔ  Ｉｎｃ．）によって配布されている。ＩＤＳは一般に、無効な「シグネチャ」のリストを含む属性ファイルを有する。ＩＤＳは、ネットワークの連続的な監視またはさらに詳細には、ユーザとアプリケーションとの間の通信の連続的な監視によってハッカーを検出し、そのような無効なシグネチャが検出される場合には、システムはセッションを終了するか、またはアクセスを拒否する。上述したように、そのようなアプローチは、属性のリストが無効な属性（この場合には「シグネチャ」）のみを含むため、当業界では「否定的アプローチ」として周知である。否定的アプローチで動作する代表的なＩＤＳは、（システム管理者が）有害な状況を無効として定義する適切な属性を導入することができるようにするために、最初に（関連するすべての結果を有する）有害な状況に直面（または通知）する必要があるという欠点を被る。
【００６８】
したがって、否定的アプローチで動作するセキュリティシステムに基づくシグネチャを用いる制限を理解し、ＩＤＳベンダは、今度は、セキュリティシステムがＨＴＴＰまたはＳＱＬ通信（または任意の他のアプリケーションプロトコル）をプロファイルすることによって、「アプリケーションの正常な挙動」を学習する、肯定的アプローチで動作する新たなセキュリティモデルに向けて動きつつある。その場合には、「正常な」アプリケーション挙動から逸脱する事象である（「不規則な事象」は一般に、決定が行われるまでシステムによってさらに査定または評価される）。この新たなアプローチは、膨大な学習および査定の試みを必要とするため、リアルタイムで解決策を常に提供することができるわけではないという重大な問題があることが分かっている。
【００６９】
この実施例によって示されているように、本発明のシステムは、上記の欠点を克服する。
【００７０】
図１における本実施例の以下の実施形態によれば、ネットワークセキュリティパッケージ６はＩＤＳであり、属性ファイル７はＩＤＳのシグネチャを含む。
【００７１】
さらに詳細には、図２を参照すると、ＩＤＳはネットワークセキュリティパッケージ６であり、ＩＤＳのシグネチャは属性ファイル７の中に含まれる。セキュリティ補正ユニット（security controlling unit）１０は、属性ファイル７を共通のフォーマットに変換し、種々のネットワーク（または他の）信頼ソース（セキュリティスキャナなど）からも他の属性を取得する。すべての属性が共通のフォーマットに変換され、前述したような処理を伴い、統合ファイルが作成される。次に、統合ファイルが（ネットワークセキュリティパッケージの）元の属性ファイルの特定のフォーマットに変換され、元の属性（シグネチャ）ファイルと置換する。このような方法で、シグネチャを含む属性ファイルは、スキャナなどの信頼ソースから受信したデータによって連続的に更新され、その結果、ＩＤＳは連続的に更新され、シグネチャ（否定的アプローチ）および他の信頼ソースから受信される別の更新された属性（肯定的アプローチ）を保持するので、肯定的な警報および／または否定的な警報を誤って提供することは少ない。
【００７２】
実施例４：
アプリケーションスイッチは、当業界では公知であるユニットである。アプリケーションスイッチの重要なタスクは、所定の一連の属性を用いて、入力トラヒックを特定のターゲットサーバに方向付けることである。さらに詳細には、方向付けは、一連の属性内のアプリケーション属性と要求に含まれる１つ以上のアプリケーションレベル属性との比較によって行われる（これは、同様に動作するネットワークスイッチと類似するが、ネットワークスイッチはネットワークレベル属性で動作する）
【００７３】
アプリケーションスイッチの使用に関する実施例は以下の通りである：
‐ウェブアプリケーションは、Ｌｏｇｉｎ．ｈｔｍｌと呼ばれる１つのＨＴＭＬページと、２つの画像ファイルｘ．ｇｉｆおよびｙ．ｇｉｆと、を有する。
‐ウェブアプリケーションは、２台のウェブサーバ、すなわち上記のＬｏｇｉｎ．ｈｔｍｌを保持する第１のＨＴＭＬファイルサーバおよび上記の２つの画像ファイルを保持する第２の画像ファイルサーバを用いて展開されている。
‐上記の２台のウェブサーバの前に、アプリケーションレベルスイッチが用いられ、画像に対するすべての要求を画像サーバへおよびＨＴＭＬファイルに対するすべての要求をＨＴＭＬファイルサーバへ切り替えるように構成される。
‐今度は、たとえば、リモートユーザがウェブアプリケーションへ要求を送信して、ｘ．ｇｉｆファイルを要求する場合を仮定する。
‐要求がアプリケーションレベルスイッチに達し、ユーザの要求からアプリケーション属性、この場合にはｘ．ｇｉｆを抽出し、その要求を最終的な宛て先としての画像ファイルサーバへ切り替える。有効な要求は、ネットワーク属性およびアプリケーション属性の両方を含むことを留意されたい。
‐上記のアプリケーションスイッチは、所定のアプリケーションレベル属性を含む属性切替表（属性スイッチングテーブル）を用いて、上記のタスクを実行する。
‐切替表（ＨＴＭＬ／画像）の中の対応する属性に適合しないアプリケーション属性を伴う任意のリモートユーザ要求は、却下され、識別されない要求を処理するために、たとえば所定のデフォルト位置（または別のサーバ）に切り替えられることになる。
【００７４】
従来技術による代表的なアプリケーションスイッチは、本質的には切替動作のみを行い、任意のセキュリティ性能に欠けている。本発明によれば、セキュリティタスクを実行するように、上記のアプリケーションスイッチを修正することができる。この点において、アプリケーションスイッチの属性表は、図３の属性ファイル３または７が用いられるのと同一の方法で用いられる。次に、セキュリティ補正ユニット１０は、アプリケーションスイッチ（スイッチは本願明細書ではセキュリティパッケージとして扱われる）の上記の表から属性をインポートし、たとえば図３に示されているように、本発明の手順を実行する。次に、（当然のことながら必要なフォーマット変換の実行後に）この手順によって作成され、複数の信頼ソース（またはセキュリティパッケージ）から収集されたセキュリティ属性を含む統合ファイルは、アプリケーションスイッチの属性表に戻るようにエクスポートされる。このような方法において、スイッチの表の中で更新される属性が、肯定的アプローチによって参照される場合には、今度はセキュリティ性能を実行することができる。さらに詳細には、アプリケーションスイッチの上記の更新される表の中に含まれるアプリケーション属性に適合しないアプリケーション属性を有する要求は、却下される。しかし、上記の更新される表の中で属性に適合する１つ以上のアプリケーション属性を含む要求のみが、方向付けられる。このような方法で、アプリケーションスイッチは、その本来の切替性能に加えて、（肯定的アプローチにおける）セキュリティ機能性を備える。
【００７５】
本発明の一部の実施形態が図によって示されているが、本発明の精神を逸脱することなく、または請求項の範囲を逸脱することなく、当業者の範囲にある種々の等価物または代替の解決策を用いて、さまざまな修正、変形および適合によって本発明を実行することができることは明白であろう。
【図面の簡単な説明】
【００７６】
【図１】従来技術によるコンピュータ環境を保護するための代表的なセキュリティシステムを示している。
【図２】本発明の一実施形態による改良されたセキュリティシステムの構造を示している。
【図３】本発明の一実施形態によるセキュリティ補正ユニットの動作をさらに詳細に示すブロック図である。
【図４】セキュリティ補正ユニットによって欠点属性レポートをインポートする手順を示している。
【図５】補正ユニットの１つの変換ステップの動作を示している。
【図６】統合ファイルを作成するための処理の一部を示している。
【図７】どのようにして属性ファイルが信頼ソースからインポートされ、共通のフォーマットにおいて対応する一時属性ファイルに変換されるかを示している。
【図８】どのようにして共通のフォーマットからパッケージ特定のフォーマットに後方変換するかを示している。
【図９ａ】セキュリティアプリケーションスキャナなどの１つの信頼ソースから得られた２つの属性コンポーネントを含むレポートの実施例を示している。
【図９ｂ】そのパッケージのセキュリティポリシーを形成するパッケージ（たとえば「ファイアウォールゲートウェイ」）特定の属性ファイルの実施例を示している。
【図１０ａ−１】統合前に空である統合ファイルの実施例を示している。
【図１０ａ−２】図１０ａ-１の続きの図である。
【図１０ａ−３】図１０ａ-２の続きの図である。
【図１０ｂ−１】図９ａのレポートを共通のフォーマットに変換し、統合ファイルのスケルトンに統合した後の統合ファイルを示している。
【図１０ｂ−２】図１０ｂ-１の続きの図である。
【図１１】共通のフォーマットにおける一時属性ファイルを示している。
【図１２】統合ファイルからの情報によって更新した後の図１１の一時属性ファイルを示している。
【図１３】本発明のシステムによって修正された最終的な更新がなされたパッケージ特定の属性ファイルを示している。さらに詳細には、図１３のこの属性ファイルは本質的に、図１０ｂの統合ファイルからの情報によって修正された対応する一時属性ファイルであり、更新されたポリシーを含む。
【図１】
2005530223.tif 000003
【図２】
2005530223.tif 000004
【図３】
2005530223.tif 000005
【図４】
2005530223.tif 000006
【図５】
2005530223.tif 000007
【図６】
2005530223.tif 000008
【図７】
2005530223.tif 000009
【図８】
2005530223.tif 000010
【図９ａ】
2005530223.tif 000011
【図９ｂ】
2005530223.tif 000012
【図１０ａ−１】
2005530223.tif 000013
【図１０ａ−２】
2005530223.tif 000014
【図１０ａ−３】
2005530223.tif 000015
【図１０ｂ−１】
2005530223.tif 000016
【図１０ｂ−２】
2005530223.tif 000017
【図１１】
2005530223.tif 000018
【図１２】
2005530223.tif 000019
【図１３】
2005530223.tif 000020
【手続補正書】
【提出日】平成16年11月10日(2004.11.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つのセキュリティパッケージによって保護されるコンピュータシステム内でセキュリティポリシーを自動的若しくは半自動的に作成および更新する方法であって、
ａ．前記システム内に少なくとも１つの信頼ソースを設け、前記システム内で動作するアプリケーションの構造または前記システム内のセキュリティの欠点を列挙するセキュリティレポートを発行することができ、前記信頼ソースの少なくとも１つがコンピュータソフトウェアの形態であるステップと、
ｂ．前記信頼ソースの各々によってレポートを発行するために、前記少なくとも１つの信頼ソースの各々を定期的に作動し、前記レポートの少なくとも１つが前記コンピュータソフトウェアの形態である信頼ソースの１つによって発行されるディジタルタイプのレポートであるステップと、
ｃ．各信頼ソースのレポートをセキュリティ補正ユニットにインポートして、すべての前記レポートからの詳細を含む１つの統合ファイルを作成するステップと、
ｄ．前記セキュリティ補正ユニットにすべてのセキュリティパッケージの属性ファイルをインポートするステップと、
ｅ．前記統合ファイルの内容と前記インポートされた属性ファイルの各々を個別に比較し、前記統合ファイル内に含まれる前記セキュリティ情報によって各属性ファイルを更新し、前記属性ファイルから欠けている情報を前記属性ファイルと関連付けるステップと、
ｆ．前記更新された属性ファイルを個別にエクスポートし、前記属性ファイルの各々を対応するセキュリティパッケージの属性ファイルとして活性化し、その結果、セキュリティポリシーを更新するステップと、を含む方法。
【請求項２】
ａ．各信頼ソースのレポートをインポートするステップが各レポートを共通のフォーマットに変換し、前記共通のフォーマットで前記統合ファイルを作成するステップをさらに含み、
ｂ．すべてのセキュリティパッケージの前記属性ファイルを前記セキュリティ補正ユニットにインポートするステップが、各属性ファイルを前記共通のフォーマットに変換するステップをさらに含み、
ｃ．前記更新された属性ファイルの各々を個別にエクスポートし、前記属性ファイルを対応するセキュリティパッケージの属性ファイルとして活性化するステップが、前記エクスポートするステップの前に、共通のフォーマットからの前記属性ファイルをパッケージ特定のフォーマットに変換するステップをさらに含む請求項１に記載の方法。
【請求項３】
前記更新するステップは、いずれかを更新して有効とし、いずれかを無視するかを決定するために、さらに所定の一連の論理規則を用いることによって行われる請求項１に記載の方法。
【請求項４】
前記レポートの各々は、少なくとも１つの属性コンポーネントを含む請求項１に記載の方法。
【請求項５】
前記発行されたレポートの各々は、対応する信頼ソース特定のフォーマットに整えられる請求項２に記載の方法。
【請求項６】
前記属性ファイルの各々は、対応するパッケージ特定のフォーマットに整えられる請求項２に記載の方法。
【請求項７】
各セキュリティパッケージは、その属性ファイルの内容に応じて、その所定の責任範囲内でセキュリティポリシーに作用する請求項１に記載の方法。
【請求項８】
１つ以上の信頼ソースは、セキュリティスキャナである請求項１に記載の方法。
【請求項９】
更新する際に含まれる一部またはすべてのステップは、オペレータの承認を必要とする半自動的な方法で実行される請求項１に記載の方法。
【請求項１０】
コンピュータソフトウェアの形態でない１つ以上の前記信頼ソースは、手動でレポートを発行する人間である請求項１に記載の方法。
【請求項１１】
前記レポートに含まれる前記属性コンポーネントの一部は、既知の欠点の問題点を除去することを目的とする属性であり、前記属性コンポーネントの一部は予測不能な問題点を除去することを目的とする属性である請求項１に記載の方法。
【請求項１２】
予測不能な問題点を除去することを目的とする前記レポートに含まれる前記属性は、前記システムの現在の構造に関連する属性であり、更新された属性ファイル内に記録されるとき、前記構造に制限されるセキュリティポリシーを強化し、前記構造から逸脱する働きを却下する属性である請求項１１に記載の方法。
【請求項１３】
セキュリティポリシーを自動的若しくは半自動的に作成および更新するシステムであり、
ａ．所定の責任範囲内でセキュリティポリシーを強化する少なくとも１つのセキュリティパッケージであって、前記ポリシーが前記パッケージの各々に関連する特定の属性ファイルによって定義されるセキュリティパッケージと、
ｂ．前記システム内で動作するアプリケーションの構造または前記システム内のセキュリティの欠点を列挙するセキュリティレポートを発行することができる少なくとも１つの信頼ソースであって、コンピュータソフトウェアの形態である前記少なくとも１つの信頼ソースと、
ｃ．セキュリティ補正ユニットであって、
‐すべての信頼ソースから前記レポートをインポートし、すべての前記レポートからの情報を含む統合ファイルを作成するため、および
‐すべてのセキュリティパッケージから前記属性ファイルをインポートし、前記統合ファイルの内容を前記インポートされた属性ファイルの各々と個別に比較し、各属性ファイルを前記統合ファイル内に含まれるセキュリティ情報によって更新し、前記属性ファイルから欠けている情報を前記属性ファイルに関連付け、前記更新された属性ファイルをエクスポートし、前記属性ファイルの各々を対応するセキュリティパッケージの属性ファイルとして活性化し、その結果、セキュリティポリシーを更新するためのセキュリティ補正ユニットと、を備えるシステム。
【請求項１４】
前記セキュリティ補正ユニットは、
‐各信頼ソースからのレポートをインポートするための少なくとも１つの第１のインポートモジュールと、
‐前記レポートの各々を受信し、すべての前記レポートに含まれる情報を含む１つの統合ファイルを作成するための統合モジュールと、
‐各セキュリティパッケージから前記補正ユニットにその対応する属性ファイルをインポートするための少なくとも１つの第２のインポートモジュールと、
‐前記統合ファイルの内容を前記インポートされた属性ファイルの各々と比較し、各属性ファイルを前記統合ファイル内に含まれる前記セキュリティ情報によって更新し、前記属性ファイルから欠けている情報を前記属性ファイルに関連付けるためのセキュリティポリシー作成モジュールと、
‐各更新された属性ファイルをその対応するセキュリティパッケージにエクスポートし、その結果、セキュリティポリシーを更新するための少なくとも１つのエクスポートモジュールと、を備える請求項１３に記載のシステム。
【請求項１５】
各レポートをその信頼ソース特定のフォーマットから共通のフォーマットに変換するための少なくとも１つの第１の変換モジュールと、各インポートされた属性のセキュリティパッケージをそのパッケージ特定のフォーマットから共通のフォーマットに変換するための少なくとも１つの第２の変換モジュールと、対応するパッケージにエクスポートする前に、各更新された属性ファイルを共通のフォーマットからそのパッケージ特定のフォーマットに変換するための少なくとも１つの第３の変換モジュールと、をさらに備え、前記統合ファイルもまた前記共通のフォーマットに整えられる請求項１４に記載のシステム。
【請求項１６】
前記セキュリティポリシー作成モジュールはさらに、前記属性ファイルを更新中に用いるための一連の所定の論理決定規則をさらに含む請求項１４に記載のシステム。
【請求項１７】
前記セキュリティパッケージの１つは侵入検出システムであり、その一連のシグネチャがファイル内に格納され、前記ファイルがセキュリティパッケージの前記属性ファイルとして処理され、その結果、それに応じて更新される請求項１３に記載のシステム。
【請求項１８】
前記セキュリティパッケージの１つはアプリケーションスイッチであり、方向付けのために用いられるその一連の属性がファイル内に格納され、前記ファイルがセキュリティパッケージの属性ファイルとして前記システムによって処理され、その結果、それに応じて更新される請求項１３に記載のシステム。
【請求項１９】
前記セキュリティパッケージの１つはアプリケーション層ファイアウォールであり、アプリケーション内の動作またはアクセスの拒否、またはアプリケーション内の正当な動作またはアクセスの許可のために用いられるその一連の属性がファイル内に格納され、前記ファイルがセキュリティパッケージの属性ファイルとして前記システムによって処理され、その結果、それに応じて更新される請求項１３に記載のシステム。
【請求項２０】
少なくとも１つの前記信頼ソースは、さらにネットワークの構造に関する詳細をセキュリティレポートに含むように構成され、少なくとも１つの前記信頼ソースによって発行された前記レポートはシステム内で動作するアプリケーションの構造およびネットワークの構造、またはシステム内のセキュリティの欠点を列挙する請求項１に記載の方法。
【請求項２１】
少なくとも１つの前記信頼ソースは、さらにネットワークの構造に関する詳細をセキュリティレポートに含むように構成され、少なくとも１つの前記信頼ソースによって発行された前記レポートはシステム内で動作するアプリケーションの構造およびネットワークの構造、またはシステム内のセキュリティの欠点を列挙する請求項１３に記載のシステム。
【国際調査報告】
2005530223.tif 000021
2005530223.tif 000022
2005530223.tif 000023
2005530223.tif 000024