JP4856970B2 - 識別された脆弱性を遮蔽するためのシステムおよび方法 - Google Patents

Description

本発明は一般に、アプリケーションの脆弱性に関し、具体的には、１つまたは複数の機能を使用不可にすることによりアプリケーションの脆弱性を遮蔽することに関する。

ユーザは、日常、幅広い機能を提供するためにさまざまなアプリケーションに依存している。たとえば、ユーザは、文書を生成するためにワード処理アプリケーションを、描画を作成するために描画プログラムを、インターネットをナビゲートするためにブラウザを使用することができる。しかし、アプリケーションは、悪意あるものからの攻撃を受けやすい。そのような攻撃は、アプリケーションおよびアプリケーションを実行するコンピューティング装置上の他のアプリケーションとのユーザの対話を妨げる。

悪意あるものは、たとえば、コンピュータウィルスの使用を通じてなど、アプリケーションの脆弱性を悪用してアプリケーションを制御することができる。１つのアプリケーションの制御が達成されると、悪意あるものの制御は、コンピュータウィルスの蔓延を通じて、他のコンピューティング装置によって実行される他のアプリケーションに伝搬することがある。たとえば、コンピュータウィルスは、コンピュータ上のアプリケーションを制御し、コンピュータ上にあるアドレス帳を調べて、アドレス帳に掲載されている各アドレスにこのウィルス自身を送信することができる。このようにして、コンピュータウィルスは、短時間のうちに多数のコンピュータにすばやく蔓延することができる。

したがって、悪意あるものの攻撃からアプリケーションを守るための改良された技法が継続的に求められている。

１つまたは複数の機能を使用不可にすることを通じてアプリケーションの脆弱性を遮蔽するためのシステムおよび方法が説明される。１つの実施例において、方法は、アプリケーションモジュールの複数の機能のうちの少なくとも１つにおいて脆弱性を識別するステップを含んでいる。識別された脆弱性からアプリケーションモジュールの実行を保護するために、複数のクライアントが受信するように通信が形成される。通信は、少なくとも１つの機能が、アプリケーションモジュールと連動した実行から使用不可にされるべきであることを記述する。

もう１つの実施例において、方法は、特定バージョンのアプリケーションモジュールの複数の機能のうちの少なくとも１つにおいて脆弱性が存在することを判定するステップを含んでいる。特定バージョンのアプリケーションモジュールを有する複数のクライアントの各々にネットワークを介して転送するように通信が形成される。通信は、脆弱性からアプリケーションモジュールの実行を保護するように、使用不可にされるべき機能を記述する。

さらにもう１つの実施例において、方法は、識別された脆弱性により、アプリケーションモジュールと連動した実行から使用不可にされるべきである複数の機能のうちの少なくとも１つを識別する通信をネットワークを介してクライアントにおいて受信するステップを含んでいる。通信に応答してクライアントが使用すべき相対適合度（ｒｅｌａｔｉｖｅ ｄｅｇｒｅｅｓ ｏｆ ｃｏｍｐｌｉａｎｃｅ）を記述するポリシーが調べられる。

説明の中の例において、類似した構造およびコンポーネントを参照するために、同じ参照番号が使用される。

概要
機能管理技法について説明する。前述のように、アプリケーションは、さまざまな方法で悪意あるものからの攻撃を受けやすい場合がある。たとえば、悪意あるものは、コンピュータウィルスの使用を通じてなど、アプリケーションの１つまたは複数の脆弱性を悪用してアプリケーションを制御することができる。アプリケーションの制御が達成されると、悪意あるもの（具体的には、コンピュータウィルス）が、他のコンピューティング装置によって実行される他のアプリケーションにすばやく伝搬することがある。

脆弱性は、さまざまな形でアプリケーションに生じることがある。たとえば、アプリケーションは、不備を含むサードパーティ製「プラグイン」を使用することがあり、そのためアプリケーションの脆弱性が攻撃を受けることになる。プラグインは、通常、プラグインを使用するアプリケーションに特定の機能（たとえばサービス）を追加するモジュールである。たとえば、プラグインは、新しい技術（たとえば新しいビデオフォーマットなど）をアプリケーションが使用できるようにサポートするために提供される。しかし、悪意あるものが首尾よくプラグインの脆弱性を突き止めた場合、悪意あるものは脆弱性を利用してアプリケーション、アプリケーションを実行するコンピュータ、および／またはコンピュータ上またはネットワークを介してアクセス可能な他のコンピュータ上にある他のアプリケーションを破壊することができる。このようにして、脆弱性はすばやく悪用され、広がって、多数のコンピューティング装置およびアプリケーションに影響を与えるが、その結果アプリケーションを使用するユーザ（たとえば、個人、企業など）に甚大な損失をもたらす場合もある。

１つの実施例において、機能管理機関が説明されるが、これはアプリケーションモジュールの機能を管理するように構成される。したがって、機能に脆弱性が識別された場合、その機能は、その機能を備えるアプリケーションの機能管理機関によって中央で使用不可にすることができる。たとえば、クライアントは、機能管理機関によって使用不可および／または使用可能にされるように構成された複数の機能を備えるアプリケーションモジュールを含むことができる。クライアントは、クライアントの機能を既知の脆弱性のリストと照合する機能管理機関と定期的に通信することができる。機能が既知の脆弱性を有する場合、機能管理機関は、アプリケーションモジュールを脆弱性から保護するために、アプリケーションモジュールと連動したクライアントによる実行からアプリケーションのどの機能が使用不可にされるべきか指定する通信を形成する。したがって、アプリケーションモジュールは、脆弱性に対する解決策が見つかるまで脆弱性から保護するためにすばやく「盾を構える」ことができ、そのため悪意あるものによる脆弱性の悪用を制限することができる。いったん発見されると、（たとえばパッチを介するなどの）解決策はクライアントに伝達されて、脆弱性を取り除き、アプリケーションモジュールを脆弱性の危険にさらすことなく機能を実行できるようにすることができる。このように、機能を使用不可にすることで、コンピュータウィルスの蔓延およびコンピュータウィルスの蔓延の原因となることからアプリケーションモジュールを保護することができる。アプリケーションモジュールに関して機能を使用不可にすることは、アプリケーションモジュール自体の一部として以下で説明されるが、機能はまた、アプリケーションモジュールの実行に影響を与える他のソフトウェアまたはハードウェア、およびハードウェアまたはソフトウェア自体の機能に含めることもできる。

クライアントは、さまざまな方法で機能を使用不可にするように構成された通信に適合することができる。たとえば、アプリケーションモジュールは、通信に適合する「方法」、つまり提案される機能の使用不可化、を指示するポリシーを調べるように構成することができる。たとえば、ポリシーは、（たとえば、クライアントとアプリケーションプロバイダ間のライセンス契約により）クライアントが通信に自動的に適合し、そのため通信を受け取り次第機能を自動的に使用不可にすることを指示することができる。もう１つの例において、ポリシーは、通信に適合して機能を使用不可にする前にネットワーク管理者による許可を必要とするように、（たとえば、管理対象企業ネットワークなどの）ネットワーク管理者によって構成することができる。さらにもう１つの例において、ポリシーは、ユーザが見るために出力され、たとえば機能を使用不可にするなど、通信によって指定されたアクションを実施するかどうかを決定するように、ユーザが指定することができる。たとえば、通信は、出力時に、脆弱性および脆弱性に対して保護するために使用不可にされる機能について記述することができる。したがって、ユーザは、機能を使用不可にするか、あるいは機能を使用可能にしておきながら脆弱性の、可能な悪用を「監視」するかどうか、十分な情報に基づいて決定することができる。その他さまざまな技法も、通信を用いて相対的な適合度（ｒｅｌａｔｉｖｅ ｄｅｇｒｅｅｓ ｏｆ ｃｏｍｐｌｉａｎｃｅ）を指定するポリシーを使用するために利用することができるが、それらについては図６に関連してさらに詳しく説明される。以下の説明では、例示的な環境は最初に、機能管理技法を採用するように動作可能な図１および図２に関して説明されている。次に例示的な手順は、説明されている例示的な環境および他の環境において動作可能な図３から図７に関して説明される。

例示的な環境
図１は、機能管理技法を使用するように動作可能な例示的な実施例における環境１００を示す図である。例示されている環境１００は、機能管理機関１０２、およびネットワーク１０６を介して相互に通信できるように結合された複数のクライアント１０４（１）、１０４（２）、．．．、１０４（Ｎ）を含んでいる。クライアント１０４（１）〜１０４（Ｎ）は、さまざまな方法で構成することができる。たとえば、クライアント１０４は、表示装置、無線電話、ゲームコンソールなどと通信できるように結合されたデスクトップコンピュータ、モバイルステーション、エンタテイメント用電気機器、セットトップボックスなど、ネットワーク１０６を介して通信することができるコンピューティング装置として構成することができる。したがって、クライアント１０４（１）〜１０４（Ｎ）は、十分なメモリおよびプロセッサリソースを備えるフルリソースの装置（たとえば、パーソナルコンピュータ、ゲームコンソールなど）から、限られたメモリおよび／または処理リソースを備えるローリソース（たとえば、従来のセットトップボックス、携帯用ゲームコンソールなど）まで多岐にわたる。クライアント１０４（１）〜１０４（Ｎ）はまた、クライアントを操作するものおよび／またはエンティティに関連することもある。つまり、クライアント１０４（１）〜１０４（Ｎ）は、ユーザ、ソフトウェアおよび／または装置を含む論理クライアントを表すことができる。

ネットワーク１０６はインターネットとして示されているが、ネットワークは多種多様な構成を想定することができる。たとえば、ネットワーク１０６は、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線ネットワーク、公衆電話網、インターネットなどを含むことができる。さらに、単一のネットワーク１０６が示されているが、ネットワーク１０６は複数のネットワークを含むように構成することができる。たとえば、クライアント１０４（１）〜１０４（Ｎ）は、企業イントラネットを介して相互に通信できるように結合され、さらに企業ネットワークゲートウェイ経由でインターネットを介して機能管理機関１０２に通信できるように結合される。さまざまな他の例も検討される。

各クライアント１０４（１）〜１０４（Ｎ）は、それぞれ複数のアプリケーションモジュール１０８（１）〜１０８（Ｎ）のうちの１つを含むように示されている。アプリケーションモジュール１０８（１）〜１０８（Ｎ）は、さまざまな機能を提供するようにさまざまな方法で構成することができる。たとえば、１つまたは複数のアプリケーションモジュール１０８（１）〜１０８（Ｎ）は、オペレーティングシステム、ワードプロセッサ、ブラウザ、インスタントメッセージモジュール、スプレッドシートアプリケーション、メモアプリケーション、写真操作アプリケーション、ゲーム、プレゼンテーションアプリケーションなどとして構成することができる。

アプリケーションモジュール１０８（１）〜１０８（Ｎ）は、さまざまな機能を提供することができる。たとえば、アプリケーションモジュール１０８（１）は、複数の機能１１０（ｆ）を含むように示されている。ここで「ｆ」は１から「Ｆ」までの任意の整数をとることができる。機能１１０（ｆ）は、さまざまな方法で提供することができる。たとえば、複数の機能１１０（ｆ）のうちの１つまたは複数の機能は、最初に書かれる場合、アプリケーションモジュール１０８（１）の一部として作成することができる。さらに、複数の機能１１０（ｆ）のうちの１つまたは複数の機能は、すでに作成されて複数のクライアント１０４（１）〜１０４（Ｎ）が使用するように配信された後、アプリケーションモジュール１０８（１）と共に使用するために「プラグイン」モジュールとして構成することもできる。たとえば、サードパーティ開発者は、新しい写真フォーマットをサポートするように構成された新しい写真ビューアなど、アプリケーションモジュール１０８（１）と共に使用するための新しい機能（たとえば機能１１０（ｆ））を作成することができる。この新しい機能（たとえば機能１１０（ｆ））をアプリケーションモジュール１０８（１）に提供するため、サードパーティ開発者は、アプリケーションモジュール１０８（１）が新しい機能を利用できるように、アプリケーションモジュール１０８（１）と連動して実行するためのプラグインモジュールを作成することができる。しかし、プラグインモジュール（たとえば機能１１０（ｆ））は、悪意あるものによって悪用される脆弱性を備えている場合もある。同様の機能は、それぞれ他のクライアント１０４（２）〜１０４（Ｎ）で実行可能な他のアプリケーションモジュール１０８（２）〜１０８（Ｎ）によって採用することができる。したがって、各々のアプリケーション１０８（１）〜１０８（Ｎ）は、環境１００の動作に全体として影響を与えるおそれのある、悪意あるものによって悪用されうる１つまたは複数の脆弱性を備えている場合もある。

図１の環境１００における機能管理機関１０２は、アプリケーションモジュール１０８（１）の機能１１０（ｆ）および他のアプリケーションモジュール１０８（２）〜１０８（Ｎ）の機能を管理するための中央システムとして示されている。たとえば、機能管理機関１０２は、機能リスト１１４を保持するために実行可能な機能管理モジュール１１２を含むことができる。機能リスト１１４は、例として、識別された脆弱性の説明、および識別された脆弱性をもたらした１つまたは複数の対応する機能を含むように構成することができる。この機能リスト１１４を使用して、機能管理モジュール１１２は、アプリケーションモジュール１０８（１）の複数の機能１１０（ｆ）のうちのどの機能が、もし悪用可能な脆弱性があったとすれば、これを含むかを判定することができる。

悪用可能な脆弱性が複数の機能１１０（ｆ）の１つまたは複数に見つかった場合、機能管理モジュール１１２は複数の通信１１６（ｋ）のうちの少なくとも１つを取得することができる。ここで「ｋ」は１から「ｋ」までの任意の整数をとることができ、通信は機能管理機関１０２によってアクセス可能なデータベース１１８に格納されるものとして示されている。複数の通信１１６（ｋ）は、さまざまな方法で取得することができる。たとえば、機能管理機関１０２は、アプリケーションモジュール１０８（１）に含まれている複数の機能１１０（ｆ）を識別するクライアント１０４（１）によって送信された通信に応答して通信１１６（ｋ）を生成することができる。もう１つの例において、通信１１６（ｋ）は、識別された場合、機能管理モジュール１１２が後で選択するために、脆弱性に対応するよう事前構成される。さまざまな他の例も検討される。

複数の通信１１６（ｋ）は、クライアント１０４（１）との通信のためにさまざまな方法で構成することができる。たとえば、通信１１６（ｋ）は、複数の機能参照１２０（ｆ）および対応する複数の機能状態指示１２２（ｆ）を備えるものとして示されている。この例における各機能参照１２０（ｆ）は、脆弱性を引き起こす複数の機能１１０（ｆ）のそれぞれ１つに対応している。各機能参照１２０（ｆ）はさらに、機能を参照したどの「状態」が脆弱性からアプリケーションモジュール１０８（１）の実行を保護するために配置されるのかを示す、対応する機能状態指示１２２（ｆ）も含んでいる。たとえば、機能参照１２０（ｆ）は、「接続」機能（たとえば機能１１０（ｆ））を参照することができ、対応する機能状態指示１２２（ｆ）は接続機能（たとえば機能１１０（ｆ））が使用不可にされることを示すことができる。もう１つの例において、通信１１６（ｋ）は、使用不可にされる機能１１０（ｆ）だけの機能参照を含み、このため機能状態指示を含まない。さまざまな他の例も検討される。たとえば、「機能状態」はバイナリ状態に限定されることはなく、「親」機能のサブ機能を使用可能または使用不可にする、完全には使用不可にされない変容状態で動作するよう機能に命令するなど、追加の細分性（ｇｒａｎｕｌａｒｉｔｙ）のための仕様を提供することができる。

通信１１６（ｋ）はさらに、脆弱性記述１２４（ｋ）を含むこともできる。たとえば、脆弱性記述１２４（ｋ）は、機能１１０（ｆ）が使用不可にされる「理由」に関してユーザが情報を得るように、各クライアント１０４（１）〜１０４（Ｎ）によって通信１１６（ｋ）が受け取られるときに出力される。したがって、脆弱性記述１２４（ｋ）は、通信１１６（ｋ）に適合するかどうかに関してクライアント１０４（１）〜１０４（Ｎ）が「自ら判断する」ことができるようにするが、これについては図５〜図７に関連して詳しく説明される。

相対適合度もまた、複数のポリシー１２６（１）〜１２６（Ｎ）の使用を通じて指定することができる。たとえば、クライアント１０４（１）は、機能管理機関１０２からの任意の通信１１６（ｋ）が自動的に実装されるように指定するポリシー１２６（１）を備えることができる。ポリシー１２６（１）は、たとえば、クライアント１０４（１）とアプリケーションモジュール１０８（１）のプロバイダとの間のライセンス契約の一部として指定することができる。もう１つの例において、ポリシーはクライアント１０４（１）に適宜組み込むことができ、ライセンス契約には含まれない。さらにもう１つの例において、クライアントグループ化１２８における各クライアント１０４（２）〜１０４（Ｎ）は、クライアント管理モジュール１３０の使用を通じて指定されるポリシー１２６（２）〜１２６（Ｎ）をそれぞれ備えることができる。たとえば、クライアントグループ化１２８は、ネットワーク管理者によって管理される企業エンティティの一部として形成することもできる。ネットワーク管理者は、クライアント管理モジュール１３０と情報をやり取りして、クライアント１０４（２）〜１０４（Ｎ）のそれぞれにポリシー１２６（２）〜１２６（Ｎ）を設定することができる。ポリシー１２６（２）〜１２６（Ｎ）は、通信１１６（ｋ）が機能管理機関１０２から受け取られたときに、ネットワーク管理者が、参照された機能を使用不可にするかどうか、およびいつ使用不可にするかを判定できるように設定することができる。したがって、ポリシー１２６（２）〜１２６（Ｎ）は、ネットワーク管理者によるアプリケーションモジュール１０８（２）〜１０８（Ｎ）の制御をサポートすることができる。さまざまな他の例も検討され、それらについては図４に関連してさらに詳しく説明される。

一般に、本明細書に説明されている機能はいずれも、ソフトウェア、ファームウェア（たとえば固定式論理回路など）、手動処理、またはこれらの実装の組み合わせを使用して実装することができる。本明細書に使用される「モジュール」および「ロジック」という用語は、一般にソフトウェア、ファームウェア、またはソフトウェアとファームウェアの組み合わせを表す。ソフトウェア実装の場合、モジュールまたはロジックは、プロセッサ（たとえば単一または複数のＣＰＵ）で実行される場合に特定のタスクを実行するプログラムコードを表す。プログラムコードは、１つ又は複数のコンピュータ可読メモリ装置に格納することができるが、これについては図２に関連して詳細に説明される。以下に説明される機能管理技法はプラットフォームに依存しない、つまりこの技法はさまざまなプロセッサを備える多種多様な市販のコンピューティングプラットフォーム上で実装できるということを意味する。

図２は、機能管理機関１０２および図１の複数のクライアント１０４（１）〜１０４（Ｎ）のうちの１つをさらに詳細に示す例示的な実施例におけるシステム２００を示す図である。図２において、クライアント１０４（ｎ）は、複数のクライアント１０４（１）〜１０４（Ｎ）のうちの１つを代表し、単一のクライアント（たとえば「クライアント１０４（ｎ）」）および複数のクライアント（たとえば「クライアント１０４（ｎ））の両方に関連して参照される。図２のシステム２００は、複数のコンピューティング装置の使用を通じて機能管理機関１０２および複数のクライアント１０４（ｎ）を実装するように示されている。たとえば、機能管理機関１０２は機能管理サーバ２０２を含むように示され、クライアント１０４（ｎ）はクライアント装置として示されている。各々の機能管理サーバおよびクライアント１０４（ｍ）は、それぞれプロセッサ２０４、２０６（ｎ）およびメモリ２０８、２１０（ｎ）を含んでいる。

プロセッサは、形成されている材質または採用されている処理メカニズムによって限定されることはない。たとえば、プロセッサは、半導体および／またはトランジスタ（たとえば電子集積回路（ＩＣ））を備えることができる。そのような状況において、プロセッサ実行可能命令は、電子的に実行可能な命令とすることができる。代替として、プロセッサの、またはプロセッサ用のメカニズム、ひいてはコンピューティング装置の、またはコンピュータ装置用のメカニズムは、量子コンピューティング、光コンピューティング、クロスバーラッチ、機械式コンピューティング（たとえば、ナノ技術を使用）などを含むことができるが、これらに限定されない。さらに、機能管理サーバ２０２およびクライアント１０４（ｎ）に対してそれぞれ単一のメモリ２０８、２１０（ｎ）が示されているが、ランダムアクセスメモリ（ＲＡＭ）、ハードディスクメモリ、取り外し可能媒体メモリなど、メモリの多種多様なタイプおよび組み合わせを採用することができる。さらに、機能管理機関に対して単一の機能管理サーバ２０２が示されているが、機能管理サーバ２０２は、サーバクラスタなどの複数のサーバを表すこともできる。

機能管理サーバ２０２は、プロセッサ２０４上で機能管理モジュール１１２を実行するように示されているが、機能管理モジュールもメモリ２０８に格納可能である。機能管理モジュール１１２は、複数のアプリケーションモジュール１０８（ｎ）の複数の機能１１０（ｆ）を管理するように実行可能である。たとえば、機能管理モジュール１１２は、どの機能１１０（ｆ）がアプリケーションモジュール１０８（ｎ）と連動した実行に対して「使用可能」または「使用不可」にされるかを制御するために実行することができる。前述のように、たとえば、機能管理モジュール１１２は、ネットワーク１０６を介してクライアント１０４（ｎ）に転送するための通信１１６（ｋ）を取得することができる。通信１１６（ｋ）は、「＜ａｔｔａｃｈｍｅｎｔ ｆｅａｔｕｒｅ＞＜ｅｎａｂｌｅｄ＞」のように、機能参照１２０（ｆ）ごとに機能状態指示１２２（ｆ）を含んでいる。

機能管理モジュール１１２はさらに、機能脆弱性識別子モジュール２１２を含むように示されている。機能脆弱性識別子モジュール２１２は、複数の機能１１０（ｆ）のうちのどの機能が攻撃を受けやすいかを判定するために実行可能な機能管理モジュール１１２の機能を代表している。この判定は、さまざまな方法で実行することができる。たとえば、機能脆弱性識別子モジュール２１２は、どの機能が対応する脆弱性を有するかを説明する図１の機能リスト１１４を使用することができる。図１の機能リスト１１４は、たとえば、コンピュータウィルスの分析に基づいてユーザが入力することができる。もう１つの例において、機能脆弱性識別子モジュール２１２は、図１の機能リスト１１４を自動的に、しかもユーザの介入なしに生成するために実行することができる。たとえば、機能脆弱性識別子モジュール２１２は、コンピュータウィルスを調べ、アプリケーションモジュール１０８（ｎ）の複数の機能１１０（ｆ）のうちのどの機能がコンピュータウィルスの攻撃対象となるかを判定するために実行することができる。さまざまな他の例も検討される。

機能脆弱性識別子モジュール２１２はさらに、バージョンモジュール２１４を含むように示されている。バージョンモジュール２１４は、アプリケーションモジュール１０８（ｎ）のうちのどのバージョンが識別された脆弱性を有しているかを判定するために実行可能な機能を代表している。たとえば、アプリケーションモジュール１０８（ｎ）は、異なるバージョンのアプリケーションモジュール１０８（ｎ）が異なる機能を有するように継続的に開発することができる。機能（どの機能が含まれるかおよび／またはどのように機能が実装されているかなど）はバージョンごとに異なるので、あるバージョンのアプリケーションモジュール１０８（ｎ）が、他のバージョンのアプリケーションモジュールでは悪用されない識別された脆弱性を有する場合もある。したがって、バージョンモジュール２１４は、アプリケーションモジュール１０８（ｎ）のどのバージョンが脆弱性を含んでいるかを判定するために実行することができる。このようにして、機能管理モジュールは、アプリケーションモジュール１０８（ｎ）のうちのどのバージョン２１６（ｎ）がクライアント１０４（ｎ）で使用可能であるか、およびその特定のバージョンが識別された脆弱性を有しているかどうかを判定することができる。バージョンおよび脆弱性については、図４に関連してさらに詳しく説明される。

クライアント１０４（Ｎ）は、メモリ２１０（ｎ）に格納されるポリシー１２６（ｎ）を含むように示されている。前述のように、ポリシー１２６（ｎ）は、アプリケーションモジュール１０８（ｎ）に対応する複数のアプリケーションライセンス２１８（ｐ）のそれぞれに基づくなど、さまざまな方法で構成することができる。ここで「ｐ」は１から「Ｐ」までの任意の整数をとることができる。たとえば、機能管理モジュール１１２は、クライアント１０４（ｎ）のアプリケーションモジュール１０８（ｎ）に対応するデータベース２２０内のアプリケーションライセンス２１８（ｐ）を見つけることができる。アプリケーションライセンス２１８（ｐ）は、アプリケーションモジュール１０８（ｎ）を使用するためにクライアント１０４（ｎ）によって入力された契約関係を記述している。アプリケーションライセンス２１８（ｐ）は、たとえば、機能管理機関１０２から受け取った通信１１６（ｋ）を自動的に実施することをクライアント１０４（ｎ）が合意していることを示すことができる。したがって、ポリシー１２６（ｎ）は、アプリケーションライセンス２１８（ｐ）を反映するように形成することができるが、これについては図５に関連してさらに詳しく説明される。

ポリシー１２６（ｎ）はさらに、通信１１６（ｋ）への応答時にクライアント１０４（ｎ）が採用すべき相対適合度を記述するように構成することもできる。たとえば、ポリシー１２６（ｎ）は、クライアント１０４（ｎ）によって実行されるさまざまな相対適合度の複数の例を含む相対コンプライアンス階層（ｒｅｌａｔｉｖｅ ｃｏｍｐｌｉａｎｃｅ ｈｉｅｒａｒｃｈｙ）２２２を有するように示される。

相対コンプライアンス階層２２２は、図２において、通信１１６（ｋ）の「可用性を通知」２２４（１）から「実装前に通知」２２４（ａ）、「自動的に実装」２２４（Ａ）まで多岐にわたるように示されている。たとえば、ポリシー１２６（ｎ）が「自動的に実装」２２４（Ａ）に設定されている場合は、クライアント１０４（ｎ）（たとえば、アプリケーションモジュール１０８（ｎ））は、「＜ａｔｔａｃｈｍｅｎｔ ｆｅａｔｕｒｅｓ＜ｄｉｓａｂｌｅ＞」などの機能参照１２０（ｆ）の機能状態指示１２２（ｆ）に従ってアプリケーションモジュール１０８（ｎ）の複数の機能１１０（ｆ）の各々を自動的に構成する。ポリシー１２６（ｎ）が「実装前に通知」２２４（ａ）に設定されている場合、アプリケーションモジュール１０８（ｎ）は、機能参照１２０（ｆ）（たとえば「接続機能」）および機能状態指示１２２（ｆ）（たとえば「使用不可」）を記述する通信１１６（ｋ）の脆弱性記述１２４（ｋ）を出力することができる。したがって、クライアント１０４（ｎ）のユーザは、たとえば接続機能を使用不可にするなど、通信１１６（ｋ）に適合するかどうかに関して十分な情報に基づいて決定することができる。同様に、ポリシー１２６（ｎ）が「可用性を通知」２２４（１）に設定されている場合、アプリケーションモジュール１０８（ｎ）は、通信１１６（ｋ）がダウンロードのために使用可能であるが、通信１１６（ｋ）をまだ取得していないことを示すメッセージを出力することができる。何であれクライアントが通信に適合していないことを指示するポリシーなどのポリシー１２６（ｎ）によって、さまざまな他の相対適合度を指定することができる。相対適合度については、図５から図７に関連してさらに詳しく説明される。

例示的な手順
以下で、前述のシステムおよび装置を使用して実装できる脆弱性保護技術について説明する。各手順の態様は、ハードウェア、ファームウェア、またはソフトウェア、あるいはこれらの組み合わせであってもよい。手順は、１つまたは複数の装置によって実行される操作を指定する一連のブロックとして示され、それぞれのブロックによる操作を実行するために示されている順序に必ずしも限定されることはない。以下の説明の一部において、図１の環境１００および図２のシステム２００に対して参照が行われる。

図３は、アプリケーションモジュールの機能に脆弱性が識別され、その脆弱性を遮蔽するためにその機能が使用不可にされ、後でアプリケーションモジュールがその機能を使用して実行できるようにする解決策が提供される例示的な実施例における手順３００を示す流れ図である。脆弱性は、アプリケーションモジュールの複数の機能のうちの少なくとも１つにおいて識別される（ブロック３０２）。たとえば、機能管理モジュール１１２は、機能脆弱性識別モジュール２１２を実行させて、アプリケーションモジュール１０８（ｎ）の複数の機能１１０（ｆ）のうちの１つまたは複数の機能が、機能リスト１１４の検査、コンピュータウィルス自体の検査を通じてなど、脆弱性を露呈することを識別させることができる。たとえば、どの機能がウィルスの攻撃対象であるかを判別するために、コンピュータウィルスを調べることができる。

次に、少なくとも１つの機能がアプリケーションモジュールと連動した実行から使用不可にされるべきであることを指示する通信が形成される（ブロック３０４）。たとえば、機能管理モジュール１１２は、アプリケーションモジュール１０８（ｎ）の脆弱性を露呈するサードパーティ製プラグインによって提供される機能１１０（ｆ）を識別することができる。したがって、通信は、サードパーティ製プラグイン（たとえば機能参照１２０（ｆ））、および使用不可などのプラグインが置かれる状態（たとえば機能状態指示１２２（ｆ））を識別することができる。

通信は次に、アプリケーションモジュールを備える複数のクライアントの各々に転送される（ブロック３０６）。たとえば、機能管理機関１０２は、ネットワーク１０６を介して通信１１６（ｋ）をクライアント１０４（１）、１０４（ｎ）、１０４（Ｎ）に転送して、各クライアント１０４（１）〜１０４（Ｎ）の機能を管理するための中央情報源としての役割を果たすことができる。次に、各クライアントは通信を適用することができるが、これについては図５に関連してさらに詳しく説明される。

次に、少なくとも１つの機能の脆弱性に対して解決策が識別される（ブロック３０８）。たとえば、ソフトウェアエンジニアのチームはコンピュータウィルスを調べて、コンピュータウィルスにより悪用される脆弱性を取り除く「パッチ」を作成することができる。次に、解決策を実装して前に使用不可にされたアプリケーションモジュールと連動して実行する機能を使用可能にするためにもう１つの通信が形成される（ブロック３１０）。たとえば、通信は「解決策」を提供するためのパッチを含むことができる。もう１つの通信は次に、アプリケーションモジュールを備える複数のクライアントの各々に転送される（ブロック３１２）。このようにして、機能に脆弱性が識別された場合、この例示的な手順３００において機能は、解決策が提供されるまで識別された脆弱性から遮蔽（つまり保護）するために使用不可にされる。したがって、この「遮蔽」は、アプリケーションモジュール自体を保護するだけでなく、このアプリケーションモジュールの悪用により攻撃を受けるおそれのある他のアプリケーションモジュールも保護することができる。

たとえば、コンピュータウィルスは、アプリケーションの特定の機能を悪用するために作成することができる。ウィルスに対する解決策が見つかるまで待って解決策を適用するのではなく、解決策を見つけるのにかかる時間の間アプリケーションモジュールを遮蔽することができる。したがって、アプリケーションモジュールは、解決策を見つけるのにかかる時間の間は攻撃を受けやすくなっていないため、ウィルスから保護される。そのような複数のクライアントで機能を使用不可にすることで、ウィルスの蔓延は制限され、防止することもできる。

図４は、ある機能におけるバージョン固有の脆弱性が識別され、特定バージョンのアプリケーションモジュールの悪用を遮蔽するために使用不可にされる例示的な実施例における手順４００を示す流れ図である。特定バージョンのアプリケーションモジュールの複数の機能のうちの少なくとも１つにおいて脆弱性が存在することが判定される（ブロック４０２）。たとえば、アプリケーションモジュールは、追加の機能を含めて、識別された脆弱性を取り除くように、アプリケーションプロバイダが継続的に開発することができる。したがって、異なるバージョンのアプリケーションモジュールは、同じ機能の実装が異なっている場合もあり、そのため、生じる可能性のある脆弱性も異なっている。それゆえ、この例において、特定バージョンのアプリケーションモジュールの特定の機能が悪用される脆弱性を備えているものとして識別される。

通信は次に、特定バージョンのアプリケーションモジュールを備える複数のクライアントの各々に対して形成される（ブロック４０４）。たとえば、機能管理モジュール１１２は、他の複数の通信と共にデータベース１１８内に格納するための通信１１６（ｋ）を形成することができる。

次にクライアントは、アプリケーションモジュールに対応するアプリケーションプロバイダにアクセスする（ブロック４０６）。たとえば、アプリケーションモジュールは、インスタントメッセージサービスにログオンして、たとえばクライアント１０４（２）など別のクライアントとインスタントメッセージセッションを開始することができる。

アクセスが達成されると、どのバージョンのアプリケーションモジュール１０８（１）がクライアント１０４（１）で使用可能であるかについて判定を行うことができる（ブロック４０８）。たとえば、クライアント１０４（１）は、ログオンプロセス中にバージョン情報を伝達することができる。次に、通信は選択され、バージョン情報に基づいてネットワークを介してクライアントに転送される（ブロック４１０）。たとえば、機能管理モジュール１１２は、アプリケーションモジュールのバージョンに対応する複数の通信１１６（ｋ）の１つを選択することができる。次に、クライアントは通信に適合することができるが（ブロック４１２）、これについては以下の図に関連してさらに詳しく説明される。

この例示的な手順４００において、どの通信が特定のクライアントに送信されるべきかについて判定が行われる。もう１つの実施例において、各通信は、形成されると各クライアントに伝達されて、クライアントは通信が関連するかどうかを判定することができる。たとえば、脆弱性がアプリケーションモジュールで識別されると、機能管理機関１０２は複数のクライアント１０４（１）〜１０４（Ｎ）の各々に通信を送信することができる。クライアント１０４（１）〜１０４（Ｎ）は（たとえば、それぞれアプリケーションモジュール１０８（１）〜１０８（Ｎ）の実行を通じて）、通信がクライアントに関連するかどうかを判定することができる。たとえば、通信は、特定バージョンのアプリケーションモジュールに脆弱性が識別されたことを指示することができる。したがって、クライアントに含まれているアプリケーションモジュールがその特定バージョンと一致しない場合、クライアントは通信が関連しないと判定することができる。さまざまな他の例も検討される。

図５は、アプリケーションモジュールの脆弱性を識別する通信に応答してクライアントが使用すべき相対適合度を決定するためにポリシーが使用される例示的な実施例における手順５００を示す流れ図である。識別された脆弱性により、アプリケーションモジュールと連動した実行から使用不可にされる複数の機能のうちの少なくとも１つを識別する通信がクライアントにおいて受信される（ブロック５０２）。たとえば、前述のように、通信１１６（ｋ）は、機能参照１２０（ｆ）（たとえば接続機能）および使用不可などの機能状態指示１２２（ｆ）を含むことができる。

通信を受信すると、通信に応答してクライアントが使用すべき相対適合度を記述するポリシーが調べられる（ブロック５０４）。たとえば、アプリケーションモジュール１０８（ｎ）は、クライアント１０４（ｎ）上でローカルに使用可能なポリシー１２６（ｎ）を調べるように実行することができる。もう１つの例において、アプリケーションモジュール１０８（ｎ）は、企業ネットワークのネットワーク管理者によって指定されているポリシーなど、クライアント管理モジュール１３０によって提供されるポリシーを調べる。ポリシー１２６（ｎ）は、通信１１６（ｋ）の受信時にクライアント１０４（ｎ）が採用すべき多種多様な相対適合度を記述することができる。

たとえば、ポリシーは、クライアントが通信に自動的に適合するよう指示することができる（ブロック５０６）。たとえば、アプリケーションモジュール１０８（ｎ）は、アプリケーションモジュール１０８（ｎ）が機能管理機関１０２から伝達される任意の通信に適合するよう命じるアプリケーションライセンス２１８（ｐ）に従うことができる。したがって、クライアント１０４（ｎ）は、この例において自動的に、通信１１６（ｋ）で指定されている少なくとも１つの機能がアプリケーションモジュール１０８（ｎ）と連動した実行から使用不可にする（ブロック５０８）。たとえば、アプリケーションモジュール１０８（ｎ）は、機能１１０（ｆ）が、他のアプリケーションモジュールとの実行からではなく、アプリケーションモジュール１０８（ｎ）との実行から使用不可にされるよう指定することができる。プラグインモジュールは、たとえば、クライアント１０４（ｎ）上でローカルに使用可能な複数のアプリケーションモジュールによって使用することができる。したがって、通信は、そのアプリケーションモジュール１０８（ｎ）のみ用の機能１１０（ｆ）の実行を使用不可にするために使用することができる。もう１つの例において、機能１１０（ｆ）の使用不可は、機能１１０（ｆ）を備えるクライアント上のすべてのアプリケーションモジュールに対して採用される。さまざまな他の例も検討される。

もう１つの例において、ポリシーは、クライアントがユーザによる検証のために通信を出力するよう指示することができる（ブロック５１０）。たとえば、クライアント１０４（ｎ）は、通信１１６（ｋ）の受信時に、前述の例（ブロック５１２）で説明されているように、機能１１０（ｆ）を自動的に使用不可にすることができる。しかし、この例において、クライアント１０４（ｎ）は、脆弱性の記述１２４（ｋ）および少なくとも１つの機能を含む通信を出力する（ブロック５１４）。次にクライアント１０４（ｎ）のユーザは、出力通信と情報をやり取りして、使用不可にされている機能を再び使用可能にさせる（ブロック５１６）。通信は、クライアントが使用不可の機能を最初に使用しようとした時点で表示、通信の受信時に即座に表示など、さまざまな方法で出力することができる。

図６は、通信はユーザが見るために出力され、通信を受信したときに使用不可にされた機能を再度使用可能にするように構成されている例示的な実施例６００を示す図である。ユーザインターフェース６０２は、図５の（ブロック５１４）においてクライアント１０４（ｎ）によって受信される通信６０４の出力を有することが示されている。通信６０４は、脆弱性および脆弱性によって影響を受ける機能の記述を含んでいる。記述は以下のように示される。

このアプリケーションの接続機能に脆弱性が識別され、使用不可にされました。
脆弱性を取り除くためのパッチが提供されるまでこの機能を使用不可のままにする場合は「同意する」を選択するか、またはこの機能を使用可能にするには「同意しない」を選択してください。
警告：同意しないを選択するとアプリケーションは攻撃を受けやすくなります。
したがってユーザは、「同意する」６０６ボタンを選択して通信１１６（ｋ）に適合するか、または「同意しない」６０８ボタンを選択して拒否することができる。このように、この例において、通信１１６（ｋ）は機能１１０（ｆ）を自動的に使用不可にするが、機能を使用可能にするという代替手段をユーザに提供する。このようにして、ユーザは、アプリケーションモジュール１０８（ｎ）のユーザの意図された使用に基づき、機能１１０（ｆ）を使用不可にすべきかどうかに関して十分な情報に基づいて決定することができる。

アプリケーションモジュール１０８（ｎ）は、たとえば、電子メールを送受信するように実行可能な電子メールアプリケーションとして構成することができる。ユーザは、なお電子メール添付ファイルの受信を望み、そのため「同意しない」６０８ボタンを選択することもできる。しかし、ユーザは、接続機能に脆弱性の可能性があることを引き続き警告され、このため、信頼できる情報源からの添付ファイルを持つ電子メールのみを受け入れるなど、接続機能の使用においてより入念になりうる。さまざまな他の例も検討される。

再び図５に戻ると、さらにもう１つの例において、ポリシーは、クライアントがユーザによる選択のために通信を出力するよう指示することができる（ブロック５１８）。次にクライアントは、脆弱性の記述および少なくとも１つの機能を含む通信を出力する（ブロック５２０）。次にユーザは、通信と情報をやり取りして、機能を再び使用不可にさせる（ブロック５２２）。したがって、この例において、機能はユーザによる同意がない限り使用不可にされることはない。

図７は、通信が、ユーザが見るために出力され、ユーザにより選択されたときに機能を使用不可にするよう構成される例示的な実施例７００を示す図である。ユーザインターフェース７０２は、図５のブロック５２０と併せて説明されているように、クライアント１０４（ｎ）による通信７０４の出力を有することが示されている。図６と同様に、通信７０４は、脆弱性および脆弱性によって影響を受ける機能の記述を含んでいる。記述は以下のように示される。
このアプリケーションの接続機能に脆弱性が識別されました。
脆弱性を取り除くためのパッチが提供されるまでこの機能を使用不可にする場合は「使用不可」を選択してください。
警告：キャンセルを選択するとアプリケーションは攻撃を受けやすくなります。
したがってユーザは、「使用不可」７０６ボタンを選択して通信１１６（ｋ）に適合するか、または「キャンセル」７０８ボタンを選択して拒否することができる。このように、この例において、通信１１６（ｋ）は機能１１０（ｆ）を自動的に使用不可にするのではなく、使用不可が望ましいかどうかユーザが選択するのを待つ。これまでのように、ユーザは、アプリケーションモジュール１０８（ｎ）のユーザの意図された使用に基づき、機能１１０（ｆ）を使用不可にすべきかどうかに関して十分な情報に基づいて決定することができる。

したがって、この手順５００において、通信に応答するためのクライアント１０４（ｎ）による実装について、自動的に通信に適合から、通信に適合して適合が望ましいことを確認、通信に適合する前に適合が望ましいことを確認までの３つの相対適合度が説明される。発明の精神および範囲を逸脱することなく、さまざまな他の相対適合度も検討される。

結論
本発明について構造的特徴および／または方法論的動作に特有の言葉で説明してきたが、添付の請求の範囲に定義されている本発明が、説明されている特定の機能または動作に必ずしも限定されないことを理解されたい。むしろ、特定の機能および動作は、特許請求された本発明を実施する例示的な形態として開示されている。

機能管理技法を採用するように動作可能な例示的な実施例における環境を示す図である。 機能管理機関および図１の複数のクライアントのうちの１つをさらに詳細に示す例示的な実施例におけるシステムを示す図である。 アプリケーションモジュールの機能に脆弱性が識別され、脆弱性を遮蔽するために機能が使用不可にされ、後にアプリケーションが機能を使用して実行できるようにする解決策が提供される例示的な実施例における手順を示す流れ図である。 機能におけるバージョン固有の脆弱性が識別され、特定バージョンのアプリケーションモジュールの攻撃を遮蔽するために使用不可にされる例示的な実施例における手順を示す流れ図である。 アプリケーションモジュールの脆弱性を識別する通信に応答してクライアントが使用すべき相対適合度を決定するためにポリシーが使用される例示的な実施例における手順を示す流れ図である。 通信はユーザが表示できるように出力され、通信の受信時に使用不可にされた機能を再度使用可能にするように構成されている例示的な実施例を示す図である。 通信はユーザが表示できるように出力され、ユーザに選択されたときに機能を使用不可にするよう構成される例示的な実施例を示す図である。

符号の説明

１０２ 機能管理機関
１０４ クライアント
１０６ ネットワーク
１０８ アプリケーションモジュール
１１０（ｆ） 機能
１１２ 機能管理モジュール
１１４ 機能リスト
１１６（ｋ） 通信
１２０（ｆ） 機能参照
１２２（ｆ） 機能状態指示
１２４（ｋ） 脆弱性記述
１２６ ポリシー
１２８ クライアントグループ化
１３０ クライアント管理モジュール
２０２ 機能管理サーバ
２０４ プロセッサ
２０６ プロセッサ
２０８ メモリ
２１０ メモリ
２１２ 機能脆弱性識別子モジュール
２１４ バージョンモジュール
２１６ バージョン
２１８ アプリケーションライセンス
２２２ 相対コンプライアンス階層
２２４ 可用性を通知
２２４ 実装前に通知
２２４ 自動的に実装

Claims (3)

1. アプリケーションモジュールを、悪意あるものによる攻撃をうける脆弱性から保護するための方法であって、
   機能管理機関の機能脆弱性識別モジュールでアプリケーションモジュールの特定のバージョンについての複数の機能のうちの少なくとも１つにおける脆弱性を識別することと、
   機能管理機関の機能管理モジュールによって、複数のクライアントによって受信される第１の通信内容を形成し、複数のクライアントは、アプリケーションモジュールの特定のバージョンを有し、識別された脆弱性からアプリケーションの実行をシールドするコンピュータデバイスであり、前記第１の通信内容は、少なくとも１つの機能がアプリケーションモジュールとともに実行から使用不可にされるべきことを記述する、ことと、
   複数のクライアントのうちの１つのクライアントによってアプリケーションモジュールに対応するアプリケーションプロバイダへアクセスすると、クライアントによって使用されているアプリケーションモジュールのバージョンが決定され、
   クライアントのアプリケーションモジュールがアプリケーションモジュールの特定のバージョンを有する場合に、ネットワークを経由してクライアントに前記第１の通信内容を転送し、
   前記クライアントが、前記第１の通信内容を受信したことに応答して、１）クライアントが当該通信内容によって自動的に動作し、それによって通信内容を受け取り次第機能を自動的に使用不可にすることと、２）通信内容に適合して機能を使用不可にする前にネットワーク管理者による許可を必要とすることと、３）ユーザが見るために出力され、通信内容によって指定されたアクションを実行するかどうかを決定することのいずれかを指定したポリシー情報に基づいて、前記クライアントが選択的に適当な動作を実行し、
   少なくとも１つの機能において、前記識別された脆弱性について修正が識別されると、ネットワークを経由して転送する、第２の通信内容を形成し、第２の通信内容は識別された脆弱性を修正し、以前使用不可にされた少なくとも１つの機能を使用可能にするためのパッチを含むことを特徴とする方法。
2. 前記アプリケーションモジュールは、
   オペレーティングシステムと、
   ワードプロセッサと、
   ブラウザと、
   インスタントメッセージモジュールと、
   スプレッドシートアプリケーションと、
   メモアプリケーションと、
   写真操作アプリケーションと、
   ゲームと、
   プレゼンテーションアプリケーションとのうちの少なくとも１つであることを特徴とする請求項１に記載の方法。
3. 前記第１の通信内容は、
   少なくとも１つの前記クライアントに自動的にユーザの介入なしに前記機能を使用不可にさせ、少なくとも１つの前記クライアントによって出力される通知を含んでおり、
   前記脆弱性を記述し、
   前記機能が自動的に使用不可にされた後に前記機能を使用可能にするための機能を提供する、
   ことを特徴とする請求項１に記載の方法。

Images