JP6086968B2 - 悪意のあるソフトウェアに対するローカル保護をするシステム及び方法 - Google Patents

Description

関連出願情報
本願は、２０１０年７月２８日に出願され「悪意のあるソフトウェアに対するネットワーク・レベル保護をするシステム及び方法(SYSTEM AND METHOD FOR NETWORK LEVEL PROTECTION AGAINST MALICIOUS SOFTWARE)」と題し、発明者がリシ・バールガーバ(Rishi Bhargava)らである同時係属米国特許出願番号１２／８４４，９６４号（代理人整理番号０４７９６．１０５３）と関連する。この出願の開示は、本明細書の一部とみなされ、参照によりその全体が本明細書に組み込まれる。

本開示は、一般にネットワーク・セキュリティの分野に関し、より詳細には悪意のあるソフトウェアに対するローカル保護に関する。

ネットワーク・セキュリティの分野は、今日の社会でますます重要になってきている。インターネットは、世界中の様々なコンピュータネットワークの相互接続を可能にした。しかしながら、安定したコンピュータ及びシステムを有効に保護し維持する機能は、部品メーカー、システム設計者及びネットワークオペレータにとって大きな課題となる。この課題は、悪意のあるオペレータによって開発される進化し続ける数々の戦略により更に複雑になる。最近の特別な懸念は、種々様々の悪意のある目的に使用されることがあるボットネットである。悪意のあるソフトウェア・プログラム・ファイル（例えば、ボット）が、一旦ホストコンピュータに感染すると、悪意のあるオペレータが、「指令制御サーバ」からコマンドを出してボットを制御することがある。ボットは、例えば、ホストコンピュータからのスパム又は悪意のある電子メールの送信、ホストコンピュータと関連付けられた企業又は個人からの機密情報の窃盗、他のホストコンピュータへのボットネットの伝播、及び／又は分散型サービス妨害攻撃の支援などのいくつもの悪意のある操作を実行するように指示されることがある。更に、悪意のあるオペレータは、指令制御サーバを介して他の悪意のあるオペレータにボットネットを販売し、その他アクセスを与えることがあり、それにより、ホストコンピュータの搾取が拡大する。

したがって、ボットネットは、悪意のあるオペレータが他のコンピュータにアクセスし、それらのコンピュータを多数の悪意のある目的のために操作する強力な方法を提供する。セキュリティ専門家は、悪意のあるオペレータがコンピュータを搾取することを可能にするような戦略を根絶する革新的ツールを開発する必要がある。

１つの例示的実施態様における方法は、計算装置上のネットワーク・アクセス試行を遮断し、ネットワーク・アクセス試行と関連付けられたソフトウェア・プログラム・ファイルを決定することを含む。この方法は、また、第１の基準を評価してネットワーク・アクセス試行が許可されるかどうかを判定し、許可されない場合にネットワーク・アクセス試行を阻止することを含む。最終的に、第１の基準は、ソフトウェア・プログラム・ファイルの信頼性状態を含む。特定の実施形態では、信頼性状態は、ソフトウェア・プログラム・ファイルが、信頼できるソフトウェア・プログラム・ファイルを識別するホワイトリストに含まれる場合に信頼できると定義され、ソフトウェア・プログラム・ファイルが、ホワイトリストに含まれない場合に信頼できないと定義される。より特定の実施形態では、ネットワーク・アクセス試行は、ソフトウェア・プログラム・ファイルが非信頼状態を有する場合に阻止される。別のより特定の実施形態では、方法は、更に、１つ又は複数のホワイトリストを検索して、ソフトウェア・プログラム・ファイルが、ホワイトリストのうちの１つの中で識別されているかどうか判定することを含む。他のより特定の実施形態では、方法は、第２の基準を評価して、第２の基準が、第１の基準を覆すかを判定することを含み、第２の基準は、ソフトウェア・プログラム・ファイルのネットワーク・アクセス・ポリシーを含む。更に別の実施形態では、ソフトウェア・プログラム・ファイルの信頼性状態が信頼されないとして定義された場合にイベントがログ記録されてもよく、そのようなログ記録は、ネットワーク・アクセス試行を阻止する代わりに行われてもよく、ネットワーク・アクセス試行を阻止することに加えて行われてもよい。

本開示及び本開示の特徴及び利点をより完全に理解するために、添付図面と関連して行われる以下の説明が参照され、図面では、類似の参照番号は類似の部品を表す。

本開示により、悪意のあるソフトウェアに対するローカル保護をするシステム及び方法の様々な実施形態を実現することができる代表的なネットワーク環境を表す図である。 本開示の実施形態によりシステムの構成要素が実現されることがあるサーバの一実施形態のブロック図である。 本開示の実施形態によりシステムの構成要素が実現されることがある例示的な計算装置の概略図である。 本開示の実施形態によるシステムと関連付けられた一連の例示的ステップを示す単純化されたフローチャートである。 本開示の実施形態によるシステムと関連付けられた信頼判定フローの一連の例示的ステップを示す単純化されたフローチャートである。 本開示の実施形態によるシステムと関連付けられた信頼判定フローの別の実施形態の一連の例示的ステップを示す単純化されたフローチャートである。 図３の計算装置の実施形態と関連付けられた一連の例示的ステップを示す単純化されたフローチャートである。 本開示の実施形態によりシステムの構成要素が実現されることがある別の例示的な計算装置の単純化された概略図である。 図８の計算装置の実施形態と関連付けられた一連の例示的ステップを示す単純化されたフローチャートである。 本開示の他の実施形態によりシステムの構成要素が実現されることがある別の例示的計算装置の単純化された概略図である。 図１０の計算装置の実施形態と関連付けられた一連の例示的ステップを示す単純化されたフローチャートである。 本開示によるシステムの信頼判定フローの別の実施形態と関連付けられた一連の例示的ステップを示す単純化されたフローチャートである。

図１は、悪意のあるソフトウェアに対するローカル保護をするシステムの１つの実施形態を実現することができる代表的なネットワーク環境１００を表す図である。ネットワーク環境１００は、中央サーバ１３０と、実行可能ソフトウェア１２２ａ、１２２ｂ及び１２２ｃをそれぞれ備えたホスト１２０ａ、１２０ｂ及び１２０ｃとを有するローカル・ネットワーク１１０を含んでもよい。ローカル・ネットワーク１１０は、例えばインターネット１５０などの広域ネットワークを含む他のネットワークへの電子接続を備えてもよい。インターネット１５０は、多くの他のネットワーク、計算装置及びウェブサービスへのアクセスを提供する。例えば、グローバルサーバ１６０は、悪意のあるコードがないと評価及び判定されたソフトウェア・プログラム・ファイルを示すグローバル・ホワイトリストを含むデータベース１６５を提供する。更に、ボットネット・オペレータ１７５などの悪意のあるユーザは、指令制御サーバ１７０のほかにインターネット１５０へのアクセスを有してもよく、指令制御サーバ１７０は、ボットネット・オペレータ１７５によって操作されて、ローカル・ネットワーク１１０などのネットワークを汚染することを試みる悪意のあるソフトウェア（例えば、ボット）を送信しその後制御してもよい。悪意のあるソフトウェアに対するローカル保護をするシステムの１つの代表的な実施形態では、ローカル保護構成要素１２４ａ、１２４ｂ及び１２４ｃは、それぞれ各ホスト１２０ａ、１２０ｂ及び１２０ｃ内に組み込まれてもよく、また中央保護構成要素１３５が、中央サーバ１３０内に組み込まれてもよい。中央サーバ１３０は、また、ログ・イベント・データベース１３１、中央非信頼ソフトウェア・インベントリ１３２、及び内部ホワイトリスト１３３へのアクセスを有してもよい。

例示的実施形態では、ホスト１２０上のローカル保護構成要素１２４と、中央サーバ１３０内の中央保護構成要素１３５が協力して、悪意のあるソフトウェアからローカル保護するシステムを提供してもよい。一実施形態では、ホスト１２０ａ、１２０ｂ及び１２０ｃの実行可能ソフトウェア１２２ａ、１２２ｂ、１２２ｃ内の各ソフトウェア・プログラム・ファイルがそれぞれ、１つ又は複数の信頼評価技術（例えば、ホワイトリスト比較、プログラム・ファイル変更比較、ブラックリスト比較など）を使用して評価されて、信頼性状態（即ち、信頼できるか信頼できないか）が判定される。中央非信頼ソフトウェア・インベントリ１３２は、信頼できないと分類された各プログラム・ファイルを識別するエントリを含むことができ、このインベントリは、対応するホスト１２０ａ、１２０ｂ及び１２０ｃ上にローカルに記憶されてもよい。他の実施形態では、信頼性状態を決定する実行可能ソフトウェア１２２ａ、１２２ｂ及び１２２ｃのソフトウェア・プログラム・ファイルの評価は、各ネットワーク・アクセス試行と関連付けられたプログラム・ファイルに対して実時間で行なわれる。本明細書で使用されるようなネットワーク・アクセス試行は、ホスト上の任意のインバウンド又はアウトバウンド・ネットワーク・アクセス試行（例えば、接続要求の受け入れ、接続要求の作成、ネットワークから電子データの受信、ネットワークへの電子データの送信）を含む。ホスト１２０ａ、１２０ｂ又は１２０ｃのうちの１つの上のソフトウェア・プロセスが、ネットワーク・アクセス試行と関連付けられたとき、ネットワーク・アクセスは、ソフトウェア・プロセスと関連付けられたどれかのプログラム・ファイルの信頼性状態が信頼できないと判定された場合に阻止されることがある。例示的な実施形態では、信頼性状態は、非信頼ソフトウェア・インベントリのうちの１つを使用して判定されてもよく、１つ又は複数の信頼評価技術を実時間で使用して判定されてもよい。非信頼プログラム・ファイルと関連付けられたソフトウェア・プロセスの阻止規則を定義するためにポリシー（例えば、ネットワーク・アドレスの指定されたサブネットへのアクセスだけを許可する、全てのインバウンド及びアウトバウンド・ネットワーク・アクセス試行を阻止する、インバウンド又はアウトバウンド・ネットワーク・アクセス試行だけを阻止する、全てのローカル・ネットワーク・アクセス試行を阻止する、インターネットトラフィックだけを許可する、など）が使用されてもよい。報告のために、非信頼プログラム・ファイルと関連付けられたソフトウェア・プロセスによる任意のネットワーク・アクセス試行がログ記録され、集計されてもよい。

悪意のあるソフトウェアに対するローカル保護をするシステムの技術を示すために、所定のネットワーク内で行われるアクティビティを理解することが重要である。以下の基本的な情報は、本開示が適切に説明される基礎とみなすことができる。そのような情報は、単に説明のために提供され、したがって、本開示とその可能な用途の広い範囲を限定するようには決して解釈されるべきではない。更に、この開示の広い範囲は、例えば、実行可能ファイル、ライブラリ・モジュール、オブジェクト・ファイル、他の実行可能モジュール、スクリプト・ファイル、インタープリタ・ファイルなど、コンピュータ上で理解され処理することができる命令を含む任意のソフトウェア・ファイルも包含する「プログラム・ファイル」、「ソフトウェア・プログラム・ファイル」及び「実行可能ソフトウェア」を指すものであることを理解されよう。

組織内又は個人によって使用される典型的なネットワーク環境は、例えばインターネットを使用して他のネットワークと電子的に通信して、インターネットに接続されたサーバ上にホストされたウェブページにアクセスし、電子メール（即ち、ｅｍａｉｌ）メッセージを送信あるいは受信し、又はインターネットに接続されたエンドユーザあるいはサーバとファイルを交換する能力を含む。悪意のあるユーザは、インターネットを使用してマルウェアを拡散し、秘密情報へのアクセスを得るための新しい戦略を開発し続けている。

コンピュータセキュリティに対する大きな脅威となる戦略は、多くの場合ボットネットを含む。ボットネットは、ある種の悪意のあるソフトウェア（即ち、ボット）がホストコンピュータに置かれて指令制御サーバと通信するクライアントサーバアーキテクチャを使用する。指令制御サーバは、悪意のあるユーザ（例えば、ボットネット・オペレータ）によって制御されてもよい。ボットは、特定の悪意のあるアクティビティを実行するコマンドを指令制御サーバから受け取り、それに応じてそのようなコマンドを実行してもよい。ボットは、任意の結果又は窃盗情報を指令制御サーバに返信してもよい。ボットは、悪意のあるアクティビティを行なうコマンドを受信する他に、典型的には、組織のネットワーク内で拡散し、又は他のネットワークを介して他の組織又は個人に拡散することができる１つ又は複数の伝搬ベクトルを含む。一般的な伝搬ベクトルは、ローカル・ネットワーク内のホスト上の既知の脆弱性を利用して、悪意のあるプログラムが添付され、又は電子メール内に悪意のあるリンクを提供する悪意のある電子メールを送信することを含む。ボットは、例えば、自動ダウンロード、ウィルス、ワーム、トロイの木馬などによりホストコンピュータに感染してもよい。

ボットネットは、様々な攻撃を使用してボットネット・オペレータがコンピュータシステムを危険にさらす強力な方法を提供する。ボットが一旦ホストコンピュータを感染すると、指令制御サーバは、ボットにコマンドを出して様々なタイプの攻撃を行なうことができる。一般に、ボットネットは、大量の電子メールを送信し分散型サービス妨害攻撃を行なうように使用されてきた。しかしながら、最近になって、ボットネットは、企業と個人に標的を絞った攻撃を行なって、知的財産や財務データなどの機密データや他の保護必要情報を得るために使用されようになった。

既存のファイアウォール及びネットワーク侵入防止技術は、一般に、ボットネットを認識しくい止めるには不十分である。ボットは、多くの場合、指令制御サーバと通信を開始し、通常のウェブブラウザトラフィックを偽装するように設計される。ボットは、ボットがウェブサーバに正常なアウトバウンド・ネットワーク接続を行っているかのように見えるようにする指令制御プロトコルによって巧妙に作成されることがある。例えば、ボットは、ウェブサーバと通信するために通常使用されるポートを使用することがある。したがって、そのようなボットは、ウェブトラフィックのより詳しいパケット検査を行なわない既存の技術では検出されないことがある。更に、ボットが発見された後、ボットネット・オペレータは、存在し続けるボットによるネットワーク・アクセス試行が、正常なウェブトラフィックを偽装する別の方法を単に見つけるだけでよい。最近になって、ボットネット・オペレータは、例えばセキュア・ソケット・レイヤー（ＳＳＬ）などの暗号化プロトコルを使用し、それにより悪意のあるネットワーク・アクセス試行を暗号化するボットを巧妙に作成した。そのような暗号化されたトラフィックは、暗号化セッションに関与するエンドポイントだけがデータを復号できるよう、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）ポートを使用することがある。したがって、既存のファイアウォールや他のネットワーク侵入防止技術は、ウェブ・トラフィックの如何なる有効な検査も実行できない。その結果、ボットは、ネットワーク内のホストコンピュータを汚染し続ける。

無許可のプログラム・ファイルがホストコンピュータ上で実行されるのを防ぐことに焦点を当てた他のソフトウェアセキュリティ技術は、企業又は他の組織的実体のエンドユーザ又は従業員に対して望ましくない副作用を有することがある。ネットワーク又は情報技術（ＩＴ）管理者は、望ましく信頼できるネットワーク資源から従業員がソフトウェアや他の電子データを取得できるようにするために、企業実体の全ての側面と関連した広範なポリシーを巧妙に作成する責任を負っていることがある。広範なポリシーが適切でないと、従業員は、そのようなソフトウェアや他のデータが企業活動に正当かつ必要な場合でも、特に許可されていないネットワーク資源からのソフトウェアや他の電子データのダウンロードを妨げられることがある。更に、そのようなシステムは、無許可のソフトウェアがホストコンピュータ上に見つかった場合に、ホストコンピュータアクティビティが延期されてネットワーク管理者の介入が保留されるという大きな制限がある。企業の場合、このタイプのシステムは、正当かつ必要な企業活動を妨げることあり、その結果、労働者の稼働不能時間、収益損失、著しい情報技術（ＩＴ）オーバヘッドなどが生じることがある。

図１に概略的に示されたような悪意のあるソフトウェアに対するローカル保護をするシステム及び方法は、感染したネットワークからのボットネットの伝搬及び悪意のあるアクティビティを減少させることができ、同時にＩＴオーバヘッドをあまり必要とせずに、感染したネットワーク内で正当なアクティビティが継続することを可能にする。１つの例示的実施態様によれば、ネットワーク内の各ホスト上のどのソフトウェア・プログラム・ファイルが危険（即ち、信頼できない）かを予め判定するシステムが提供される。一例では、この判定は、ホスト上に常駐する未知又は変更されたプログラム・ファイルを検出することにより行われる。ネットワーク・アクセス試行（即ち、インバウンド又はアウトバウンド）が、ネットワーク内のホストのうちの１つで行われるときは、ネットワーク・アクセス試行と関連付けられたプロセスが評価されてその対応プログラム・ファイル又はファイルが決定され、そのプログラム・ファイル又はファイルが評価されてその信頼性状態（即ち、信頼できるか信頼できないか）が判定される。各プログラム・ファイルが信頼できる場合は、そのプロセスと関連付けられたネットワーク・アクセス試行が、許可されることがある。しかしながら、プログラム・ファイルのどれかが信頼できない場合は、プロセスと関連付けられたネットワーク・アクセス試行が阻止され、それにより、可能性のあるボットの伝搬と悪意のあるアクティビティは防止されることがある。１つの例示的実施形態では、ネットワーク・アクセスは、ポリシー構成に基づいて、サブネットの定義された組に対して及び／又はその組から選択的に許可されることがある。したがって、ボットが指令制御サーバからのコマンドに応答し伝搬する能力が、大幅に縮小され、同時に必要な企業活動の中断又は妨害が最小になる。その結果、図１に実現されたようなシステムは、感染ホストがあるネットワーク、及び感染ホストがアクセスを試みる他のネットワークに対してよりよい保護を提供する。

図１のインフラストラクチャに移ると、ローカル・ネットワーク１１０は、コンピュータシステムを保護するシステムを実現することができる例示的なアーキテクチャを表す。ローカル・ネットワーク１１０は、１つ又は複数のローカル・エリア・ネットワーク（ＬＡＮ）、他の適切なネットワーク、又はこれらの任意の組み合わせ含む様々な形態で構成されてもよい。インターネット１５０は、ローカル・ネットワーク１１０が適切に接続されることがある広域ネットワーク（ＷＡＮ）を表す。一実施形態では、ローカル・ネットワーク１１０は、インターネットサービスプロバイダ（ＩＳＰ）によって、又は専用帯域幅を有するインターネットサーバを介して、インターネット１５０に動作的に結合されてもよい。ローカル・ネットワーク１１０とインターネット１５０間の接続は、例えばデジタル加入者線（ＤＳＬ）、電話線、Ｔ１線、Ｔ３線、ワイヤレス、衛星、光ファイバ、ケーブル、イーサネット（登録商標）など、又はこれらの任意の組み合わせのような任意の適切な媒体も含んでもよい。更に、ゲートウェイ、スイッチ、ルータなどを使用して、ホスト１２０と中央サーバ１３０とインターネット１５０との間の電子通信を容易にしてもよい。ＩＳＰ又はインターネット・サーバは、ホスト１２０が伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を使用してインターネット上の他のノードと通信できるように構成されてもよく、メールサーバ（図示せず）は、ホスト１２０が簡易メール転送プロトコル（ＳＭＴＰ）を使用して電子メールメッセージを送受信できるようにしてもよい。

１つの例示的実施形態では、ローカル・ネットワーク１１０は、組織（例えば、企業、学校、政府実体、家族など）と関連付けられた従業員又は他の個人によって操作されるエンドユーザ・コンピュータを表わすホスト１２０ａ、１２０ｂ及び１２０ｃを有する組織のネットワーク環境を表わす。エンドユーザ・コンピュータは、デスクトップ、ラップトップ、可搬型又は携帯型計算装置（例えば、携帯情報端末（ＰＤＡ）又は携帯電話）などの計算装置、又はローカル・ネットワーク１１０へのネットワーク・アクセスと関連付けられたソフトウェア・プロセスを実行することができる他の計算装置を含んでもよい。ローカル・ネットワーク１１０内のホスト１２０ａ、１２０ｂ及び１２０ｃ、中央サーバ１３０、並びに任意の追加の構成要素の間の接続は、例えば、ケーブル、イーサネット（登録商標）、ワイヤレス（例えば、ＷｉＦｉ、３Ｇ、４Ｇなど）、ＡＴＭ、光ファイバなどの任意の適切な媒体を含んでもよい。本明細書に示され述べられたネットワーク構成及び相互接続が、単に説明のためのものであることに注意されたい。図１は、例として意図され、本開示におけるアーキテクチャの限定を意味するように解釈されるべきではない。

図１に示された例示的実施形態では、指令制御サーバ１７０とボットネット・オペレータ１７５が、インターネット１５０に動作的に結合される。一例では、指令制御サーバ１７０は、分散型ボットにコマンドを出すようにボットネット・オペレータ１７５によって制御又は使用されるウェブサーバでよい。別の例では、指令制御サーバ１７０は、大企業、教育機関あるいは政府機関のサイトに悪意を持ってインストールされ隠されていてもよい。ボットネット・オペレータ１７５は、例えば、インターネット１５０を介して指令制御サーバ１７０にリモートでアクセスして、ホスト１２０ａ、１２０ｂ又は１２０ｃなどの感染ホストコンピュータ上の分散型ボットを制御する命令を出してもよい。多数のボットネット・オペレータと、何百万台ものボットを制御する指令制御サーバが、インターネット１５０に動作的に接続されてもよい。一例では、ボットが、ホスト１２０ａ、１２０ｂ又は１２０ｃのうちの１つに感染すると、ボットネット・オペレータ１７５は、指令制御サーバ１７０を介してコマンドを出して、ボットをローカル・ネットワーク１１０及び／又はの他のネットワークの全体に伝搬させ始める。更に、ボットネット・オペレータ１７５は、感染ホスト１２０ａ、１２０ｂ又は１２０ｃから、スパム電子メール、秘密情報の盗難、分散型サービス妨害攻撃などの悪意のあるアクティビティをボットが試みる命令を出すことがある。

図１は、また、インターネット１５０に接続されたグローバルサーバ１６０を示す。多数のサーバがインターネット１５０に接続されてもよいが、グローバルサーバ１６０は、リスクが評価されたソフトウェア・プログラム・ファイルに関係する情報を含む１つ又は複数のデータベースを提供するサービスを提供する。例えば、信頼できない（例えば、ウィルス、ワームなどの悪意のあるコードを含む）と評価及び判定されたソフトウェア・プログラム・ファイルが、いわゆる「ブラックリスト」に含まれてもよい。信頼できる（例えば、汚染されていない、悪意のあるコードを含まないなど）と評価及び判定されたソフトウェア・プログラム・ファイルが、いわゆる「ホワイトリスト」に含まれてもよい。ホワイトリストとブラックリストは、別々に実施されてもよいが、各ソフトウェア・プログラム・ファイルが、ホワイトリストファイル又はブラックリストファイルとして識別されるデータベース内で結合されてもよい。

ホワイトリスト及びブラックリストは、各プログラム・ファイルの固有チェックサムが記憶されたチェックサムを使用して実施されてもよく、このチェックサムは、評価されるプログラム・ファイルの計算済みチェックサムと容易に比較することができる。チェックサムは、ソフトウェア・プログラム・ファイルにアルゴリズムを適用することによって導出された数値又はハッシュサム（例えば、番号数字の固定文字列）でよい。アルゴリズムが、第１のソフトウェア・プログラム・ファイルと同一の第２のソフトウェア・プログラム・ファイルに適用された場合は、チェックサムが合致しなければならない。しかしながら、第２のソフトウェア・プログラム・ファイルが異なる場合（例えば、第２のソフトウェア・プログラム・ファイルが、何らかの方法で変更された場合、第１のソフトウェア・プログラム・ファイルの異なるバージョンである場合、全く異なるタイプのソフトウェアである場合など）は、チェックサムは合致しない可能性が極めて高い。

図１のグローバル・ホワイトリスト１６５などのデータベースは、独立した第三者によって提供されてもよく、消費者が入手可能な信頼できるソフトウェア・プログラム・ファイルの総合リストを提供するように定期的に更新されてもよい。同様に、ブラックリスト（図示せず）は、独立した第三者によって提供されてもよく、信頼できない悪意のあるソフトウェア・プログラム・ファイルの総合リストを提供するように定期的に更新されてもよい。グローバル・ホワイトリスト及びブラックリストは、ローカル・ネットワーク１１０の外部にあってもよく、インターネット１５０などの他のネットワークを介して、又はローカル・ネットワーク１１０とグローバル・ホワイトリスト１６５との間の電子通信を可能にする任意の他の適切な接続を介してアクセス可能でよい。そのようなグローバル・ホワイトリスト及びブラックリストの例には、カリフォルニア州サンタクララのＭｃＡｆｅｅ社によって提供されるＡｒｔｅｍｉｓデータベースと、オレゴン州ポートランドのＳｉｇｎａＣｅｒｔ社によって提供されるＳｉｇｎａＣｅｒｔ（登録商標）データベースが含まれる。

図１は、また、ローカル・ネットワーク１１０内に示された内部ホワイトリスト１３３を含む。内部ホワイトリスト１３３は、また、リスクが評価されたソフトウェア・プログラム・ファイルに関係する情報を含んでもよく、チェックサムを使用してそのようなソフトウェア・プログラム・ファイルを識別してもよい。内部ホワイトリスト１３３内で識別されるソフトウェア・プログラム・ファイルは、１つ又は複数のグローバル・ホワイトリストからのソフトウェア・プログラム・ファイルを包含してもよく、かつ／又は選択されたソフトウェア・プログラム・ファイルを提供するようにカスタマイズされてもよい。詳細には、組織内部で開発されたが必ずしも一般大衆が入手できるとは限らないソフトウェア・プログラム・ファイルが、内部ホワイトリスト１３３内で識別されてもよい。更に、信頼できないと評価及び判定された特定のソフトウェア・プログラム・ファイルを識別するために、内部ブラックリストが提供されてもよい。

図１に示された例示的実施形態では、ホスト１２０ａ、１２０ｂ及び１２０ｃの実行可能ソフトウェア１２２ａ、１２２ｂ及び１２２ｃは、本明細書で前に述べたように、任意の実行可能ファイル、ライブラリ・モジュール、オブジェクト・ファイル、他の実行可能モジュール、スクリプト・ファイル、インタープリタ・ファイルなどを含むことがある複数のソフトウェア・プログラム・ファイルをそれぞれ有してもよい。ホスト１２０ａ、１２０ｂ及び１２０ｃのうちの１つにボットが感染した場合、ボットは、それぞれのホストの実行可能ソフトウェア１２２ａ、１２２ｂ又は１２２ｃ内のプログラム・ファイルとして記憶される可能性がある。ローカル保護構成要素１２４ａ、１２４ｂ及び１２４ｃは、それぞれのホスト１２０ａ、１２０ｂ及び１２０ｃ上のインバウンドとアウトバウンド両方のネットワーク・アクセス試行を遮断することがある。ネットワーク・アクセス試行と関連付けられた任意のプログラム・ファイルが、非信頼状態を有する場合、ネットワーク・アクセスは、他の基準（例えば、ポリシー、既定条件など）に基づいて阻止されるか選択的に許可されてもよい。しかしながら、プログラム・ファイルが信頼状態を有する場合は、ネットワーク・アクセスは許可されることがある。

幾つかの実施形態では、中央サーバ１３０の中央保護構成要素１３５は、実行可能ソフトウェア１２２ａ、１２２ｂ及び１２２ｃの各プログラム・ファイルを評価し、各プログラム・ファイルを信頼できるか信頼できないか分類する。プログラム・ファイルは、内部ホワイトリスト１３３、グローバル・ホワイトリスト１６５、内部あるいは外部ブラックリスト、又はこれらの任意の組み合わせと比較されてもよい。評価されたプログラム・ファイルが、信頼できないと分類された場合、非信頼プログラム・ファイルを識別するエントリが、中央非信頼ソフトウェア・インベントリ１３２に加えられることがある。中央サーバ１３０は、また、ローカル・ネットワーク１１０内の任意のホスト１２０ａ、１２０ｂ及び１２０ｃ上のネットワーク・アクセス試行に関係する情報を含むログ・イベント・データベース１３１を維持してもよい。ログ・イベント・データベース１３１、中央非信頼ソフトウェア・インベントリ１３２及び内部ホワイトリスト１３３は、中央サーバ１３０にアクセス可能な任意のネットワーク及び装置内に提供されてもよい。

図２に移ると、図２は、中央サーバ２００及び関連したメモリ構成要素２３１、２３２及び２３３の概略図を示す。これは、図１に示された中央サーバ１３０及び関連したメモリ構成要素１３１、１３２及び１３３の詳細な例である。システムの１つの例示的実施形態では、中央サーバ２００の中央保護構成要素は、管理保護モジュール２２０、ポリシー・モジュール２３０、ポリシー・データベース２３５、及びソフトウェア信頼判定モジュール２４０を含んでもよい。１つの例示的実施形態では、ソフトウェア信頼判定モジュール２４０から信頼プログラム・ファイルキャッシュエントリを受け取るための中央信頼キャッシュ２４５を含んでもよい。しかしながら、他の実施形態では、中央サーバ２００が、非信頼プログラム・ファイルエントリを記憶するための中央非信頼ソフトウェア・インベントリ２３２を収容するメモリ構成要素を含むか又はそのメモリ構成要素へのアクセスを有してもよい。中央サーバ２００は、また、プロセッサ２８０やメモリ要素２９０などの適切なハードウェア要素に加えて、ログ・イベント・データベース２３１や内部ホワイトリスト２３３などのメモリ構成要素を含むか又はそれらのメモリ構成要素へのアクセスを有してもよい。許可された人が、例えば管理保護モジュール２２０を介してシステムを展開し、構成し、維持するために、中央サーバ２００が、管理コンソール２１０に適切に接続されてもよい。

中央信頼キャッシュ２４５を使用する実施形態では、キャッシュは、グローバル及び／又は内部ホワイトリストを検索する際に見つかったプログラム・ファイルなど、以前に信頼状態を有すると判定されたプログラム・ファイルを識別するエントリ（例えば、チェックサム）を一時的に記憶するためのメモリのブロックとしてハードウェア内に実現されてもよい。中央信頼キャッシュ２４５は、以前に信頼性状態が評価されたプログラム・ファイルを示すデータに対する迅速かつ透明なアクセスを提供することができる。これにより、要求されたプログラム・ファイルが、中央信頼キャッシュ２４５内に見つかった場合は、グローバル及び／又は内部ホワイトリストの検索、又は任意の他の信頼評価が行なわれなくてもよいことがある。更に、中央信頼キャッシュ２４５を使用する実施形態は、中央非信頼ソフトウェア・インベントリ２３２を維持しなくてもよい。

図３に移ると、図３は、悪意のあるソフトウェアに対するローカル保護をするシステムが実現することができる、計算装置又はホスト３００の一実施形態の概略図と中央サーバ２００のブロック図とを示す。ホスト３００は、図１のホスト１２０のより詳細な例である。ホスト３００は、例えば、プログラム・ファイル１〜ｎを含む１組の実行可能ソフトウェア３４０を含む。ホスト３００内のローカル・ネットワーク保護構成要素は、ローカル保護モジュール３１０、ソフトウェア管理モジュール３２０、ローカル非信頼ソフトウェア・インベントリ３３０、及びソフトウェア・プログラム・インベントリ・フィード３３５を含んでもよい。ソフトウェア管理モジュール３２０、ローカル非信頼ソフトウェア・インベントリ３３０、及びソフトウェア・プログラム・インベントリ・フィード３３５は、ホスト３００のユーザ空間内に常駐してもよい。また、ホスト３００のユーザ空間内には、実行可能ソフトウェア３４０のプログラム・ファイルの１つ又は複数に対応する例示的な実行ソフトウェア・プロセス３４５が示されている。参照し易くするため、実行可能ソフトウェア３４０は、ホスト３００上のユーザ空間内に示されるが、ホスト３００上のディスクドライブなどのメモリ要素に記憶されてもよい。

ホスト３００は、また、ネットワーク・インタフェース・カード（ＮＩＣ）装置３７０、プロセッサ３８０、メモリ要素３９０などのハードウェア構成要素を含んでもよい。ローカル保護モジュール３１０、及び伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）３５０や他のプロトコル３６０などの伝送プロトコルは、ホスト３００のカーネル空間内に常駐してもよく、ＮＩＣ装置３７０とインタフェースするネットワーク・ドライバ・インタフェース仕様（ＮＤＩＳ）ドライバ・スタックの一部として実現されてもよい。オペレーティング・システム・カーネルは、ソフトウェア・プロセスを実行可能ソフトウェア３４０のその対応プログラム・ファイルにマッピングするプロセス・トラフィック・マッピング要素３６５を提供する。

ソフトウェア管理モジュール３２０と中央サーバ２００との間には、ポリシー更新フロー３２２、非信頼ソフトウェア更新フロー３２４及びイベント・フロー３２６を含むデータ・フローが示される。ソフトウェア管理モジュール３２０とローカル保護モジュール３１０との間には、ポリシー更新フロー３１２、制御フロー３１８及びイベント・フロー３１６を含むデータ及び制御フローも示される。最後に、ソフトウェア・プログラム・インベントリ・フィード３３５が、中央サーバ２００へのデータ・フロー３３７と共に示される。

図２と図３には、メモリ管理ユニット（ＭＭＵ）、付加的対称型マルチプロセッシング（ＳＭＰ）要素、物理メモリ、イーサネット（登録商標）、周辺構成要素相互接続（ＰＣＩ）バス及び対応ブリッジ、小型コンピュータシステム・インタフェース（ＳＣＳＩ）／Ｉｎｔｅｇｒａｔｅｄ Ｄｒｉｖｅ Ｅｌｅｃｔｒｏｎｉｃｓ（ＩＤＥ）要素などの形でプロセッサ２８０及び３８０に適切に結合されてもよい追加のハードウェアが示されていない。更に、ネットワーク・アクセスを可能にするため、適切なモデム及び／又は追加のネットワーク・アダプタを含んでもよい。中央サーバ２００とホスト３００は、意図された機能を適切に実行するのに必要な任意の追加のハードウェア及びソフトウェアを含んでもよい。更に、中央サーバ２００及びホスト３００内に、その中のハードウェア構成要素の動作を適切に管理するため、任意の適切なオペレーティング・システムが構成されてもよい。ハードウェア構成は異なってもよく、示された例がアーキテクチャの限定を意味するものではないことを理解されよう。

実行可能ソフトウェア３４０の信頼判定及びログ記録アクティビティは、例示的な実施形態では、少なくとも部分的に、中央サーバ２００の管理保護モジュール２２０とソフトウェア信頼判定モジュール２４０によって、またホスト３００のソフトウェア・プログラム・インベントリ・フィード３３５、ソフトウェア管理モジュール３２０及びローカル保護モジュール３１０によって提供されてもよい。信頼判定及びログ記録アクティビティと関係した情報は、適切に描写されるか、特定の場所（例えば、ローカル非信頼ソフトウェア・インベントリ３３０、ログ・イベント・データベース２３１など）に送信されるか、単純に記憶又はアーカイブされるか（例えば、中央非信頼ソフトウェア・インベントリ２３２など）、かつ／又は任意の適切な形式で適切に表示されてもよい（例えば、管理コンソール２１０など）。１つ又は複数のそのような信頼判定及びログ記録アクティビティと関係したセキュリティ技術には、ｅＰｏｌｉｃｙ Ｏｒｃｈｅｓｔｒａｔｏｒソフトウェア、Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌソフトウェア、及び／又はＣｈａｎｇｅ Ｃｏｎｔｒｏｌソフトウェア（全てカリフォルニア州サンタクララのＭｃＡｆｅｅ社によって製造された）、又は任意の他の類似ソフトウェアなどの要素を含むことができる。したがって、本明細書で使用されるような用語「管理保護モジュール」、「ソフトウェア信頼判定モジュール」、「ソフトウェア・プログラム・インベントリ・フィード」、「ソフトウェア管理モジュール」及び「ローカル保護モジュール」の広い範囲には、任意のそのような構成要素が含まれることがある。ログ・イベント・データベース２３１、中央非信頼ソフトウェア・インベントリ２３２、内部ホワイトリスト２３３、及びローカル非信頼ソフトウェア・インベントリ３３０は、電子データの信頼判定及びログ記録と関連した情報（例えば、プログラム・ファイルの信頼判定、ソフトウェア・プロセスのネットワーク・アクセス試行など）を含むことがあり、これらの要素は、中央サーバ２００及びホスト３００のモジュール及び構成要素と容易に協力し、連係し、その他相互作用することができる。

ネットワーク・アクセス試行の遮断及び阻止アクティビティは、例示的な実施形態では、少なくとも部分的に、ホスト３００のローカル保護モジュール３１０とソフトウェア管理モジュール３２０、及び中央サーバ２００の管理保護モジュール２２０とポリシー・モジュール２３０内で提供されてもよい。遮断及び阻止アクティビティと関連した情報は、特定の場所（例えば、中央サーバ２００、ログ・イベント・データベース２３１、ローカル保護モジュール３１０など）にプッシュされ、単にローカルに記憶又はアーカイブされ、かつ／又は任意の適切な形式で適切に表示されてもよい（例えば、管理コンソール２１０などにより）。１つ又は複数のそのような遮断及び／又は阻止アクティビティと関連したセキュリティ技術は、ＭｃＡｆｅｅ（登録商標）ｅＰｏｌｉｃｙ Ｏｒｃｈｅｓｔｒａｔｏｒソフトウェアや他の類似のソフトウェアなどの要素を含んでもよい。したがって、本明細書で使用されるような用語「ローカル保護モジュール」、「ソフトウェア管理モジュール」、「管理保護モジュール」及び「ポリシー・モジュール」の広い範囲内に、任意のそのような構成要素が含まれることがある。ローカル非信頼ソフトウェア・インベントリ３３０、中央非信頼ソフトウェア・インベントリ２３２、及びポリシー・データベース２３５は、ネットワーク・アクセス試行の遮断及び阻止と関連した情報（例えば、プログラム・ファイルの信頼判定、ポリシー構成など）を含んでもよく、これらの要素は、中央サーバ２００及びホスト３００のモジュール及び構成要素により容易にアクセスされ、その他相互作用することができる。

図４〜図７は、悪意のあるソフトウェアからローカル保護するシステムの実施形態と関連付けられた例示的ステップのフローチャートを含む。参照し易くするため、図４から図７は、ここでは、図１のネットワーク環境１００内の特定の構成要素、並びにサーバ２００、ホスト３００、及びその関連した構成要素、要素、モジュールに関して記述されるが、本明細書に示され記載されたシステムと方法を実現するために、様々な他の装置、構成要素、要素、モジュールなどが使用されてもよい。

図４と図５はそれぞれ、中央非信頼ソフトウェア・インベントリ２３２及び／又はローカル非信頼ソフトウェア・インベントリ３３０を作成し維持する列挙フロー４００と信頼判定フロー５００を示す。フロー４００は、少なくとも部分的に中央サーバ２００のソフトウェア信頼判定モジュール２４０内で行われてもよい。最初にステップ４１０で、ホスト３００上の実行可能ソフトウェアのインベントリが取得される。例示的な実施形態では、このソフトウェア・インベントリは、ホスト３００のソフトウェア・インベントリ・フィード３３５から受け取ってもよい。ソフトウェア・インベントリ・フィードは、ホスト３００上の実行可能ソフトウェア３４０のプログラム・ファイルを全て列挙し、列挙したプログラム・ファイル（即ち、ソフトウェア・インベントリ）をデータ・フロー３３７によって中央サーバ２００にプッシュしてもよい。他の実施形態では、実行可能ソフトウェア３４０の新しい及び変更されたプログラム・ファイルだけが中央サーバ２００に列挙されプッシュされる。そのような列挙は、例えば、Ｐｏｌｉｃｙ ＡｕｄｉｔｏｒソフトウェアやＡｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌソフトウェアなどの既存のセキュリティ技術によって達成することができる。これらのソフトウェアは両方とも、カリフォルニア州サンタクララのＭｃＡｆｅｅ社によって製造されたものである。

ステップ４１０でプログラム・ファイルが列挙された後、ソフトウェア・インベントリで識別されたプログラム・ファイルがそれぞれ評価され、信頼性状態が判定され、信頼できる（即ち、ネットワーク・アクセスが許可されることがある）か信頼できない（即ち、ネットワーク・アクセスが阻止されるか選択的に許可されることがある）かに分類される。ステップ４１０の後、フローはステップ４２０に進んでもよく、最初のプログラム・ファイルが、ソフトウェア・インベントリから取り出される。次に、フローは、ステップ４３０に進み、プログラム・ファイルが、評価され、信頼できるか信頼できないかに分類される。これについては、図５と図６に関連して本明細書で更に示され述べられる。ステップ４３０でプログラム・ファイルが信頼できるか信頼できないかに分類された後、フローは、ステップ４４０に進み、現在評価されているプログラム・ファイルが、中央サーバ２００がホスト３００から受け取ったソフトウェア・インベントリ内の最後のプログラム・ファイルかどうかの判定がされる。現在のプログラム・ファイルが、ソフトウェア・インベントリ内の最後のプログラム・ファイルでない場合は、ステップ４５０でソフトウェア・インベントリから次のプログラム・ファイルが取り出されることがあり、フローは、ステップ４３０にループして戻って次のプログラムの評価と信頼分類を開始する。しかしながら、ステップ４４０で、現在のプログラム・ファイルが、ソフトウェア・インベントリ内の最後のプログラム・ファイルの場合、フローはステップ４６０に進む。

ステップ４６０で、新しく分類された信頼できないプログラム・ファイルがホスト３００にプッシュされ、ローカル非信頼ソフトウェア・インベントリ３３０を更新することがある。プッシュは、非信頼ソフトウェア更新フロー３２４により、中央サーバ２００のソフトウェア信頼判定モジュール２４０から、ホスト３００のソフトウェア管理モジュール３２０に行われることがある。例示的実施形態では、中央サーバ２００のソフトウェア信頼判定モジュール２４０は、ホスト３００上の完全なソフトウェア・インベントリのソフトウェア・プログラム・インベントリ・フィード３３５又はホスト３００上の新しいか変更されたプログラム・ファイルのソフトウェア・インベントリから、一定のフィード又はほぼ一定のフィードを受け取ることができ、その結果、中央非信頼ソフトウェア・インベントリ２３２及び／又はローカル非信頼ソフトウェア・インベントリ３３０は、実質的に実時間で最新になる。他の実施形態では、ソフトウェア信頼判定モジュール２４０は、列挙されたソフトウェア・インベントリを定期的な間隔（例えば、毎日、１時間毎、３０分毎など）で受け取ってもよい。

図５に移ると、図５は、図４のステップ４３０に対応する信頼判定フロー５００のより詳細なフローを示す。これは、中央サーバ２００にプッシュされたソフトウェア・インベントリ内の各プログラム・ファイルについて実行される。フローは、ステップ５１０で始まってもよく、現在のプログラム・ファイルが評価されて、それが、図１に示されたグローバル・ホワイトリスト１６５などの少なくとも１つのグローバル・ホワイトリスト上、及び／又はローカル・ネットワーク１１０外の他のホワイトリスト上で識別されたかどうかが判定される。本明細書で前に述べたように、プログラム・ファイルを識別するために、ホワイトリスト内でチェックサムが使用されてもよい。ステップ５１０でプログラム・ファイルがグローバル又は他の外部ホワイトリストのいずれかに見つかった場合は、プログラム・ファイルの信頼性状態が、信頼できると定義され、その結果、フローが終了し、中央非信頼ソフトウェア・インベントリ２３２を更新しないことにより、プログラム・ファイルは、信頼できるとして分類される。しかしながら、ステップ５１０で、プログラム・ファイルが、グローバル又は他の外部ホワイトリスト上に見つからなかった場合は、フローはステップ５２０に進み、内部ホワイトリスト２３３などの１つ又は複数の内部ホワイトリストが検索されてもよい。組織は、複数のホワイトリスト（例えば、組織全体のホワイトリスト、企業レベルのホワイトリストなど）を使用してもよい。プログラム・ファイルが、内部ホワイトリストのどれかに見つかった場合、プログラム・ファイルの信頼性状態が、信頼できるとして定義され、その結果、フローは終了し、中央非信頼ソフトウェア・インベントリ２３２は更新されない。

しかしながら、ステップ５１０又は５２０で、プログラム・ファイルが内部又は外部ホワイトリストのどれにも見つからなかった場合、プログラム・ファイルは、非信頼状態を有する。次に、フローは、ステップ５３０に進んでもよく、プログラム・ファイルが評価されて、そのプログラム・ファイルが、プログラム・ファイルを非信頼状態から信頼状態に昇格させることができる任意の既定条件を満たすかどうかが判断されることがある。そのような既定条件には、例えば、管理者が所有するソフトウェア、ファイルアクセス制御、ファイル属性（例えば、作成時刻、修正時刻など）などのヒューリスティックな検討事項が含まれてもよい。一例では、管理者が所有する非信頼プログラム・ファイルは、信頼状態に昇格されることがあり、その結果、フローは終了し、プログラム・ファイルは、中央非信頼ソフトウェア・インベントリ２３２を更新しないことによって信頼できると分類される。しかしながら、ステップ５３０で、プログラム・ファイルが既定条件を満たさない場合は、非信頼状態が持続し、プログラム・ファイルは、最後のステップ５４０で、プログラム・ファイルを識別する中央非信頼ソフトウェア・インベントリ２３２を更新することによって、信頼できないとして分類されてもよい。

信頼判定フロー５００は、また、ホワイトリストに加えてブラックリストを評価する追加の論理（図示せず）を含んでもよい。ブラックリストは、悪意のあることが分かっているソフトウェア・プログラム・ファイルを識別する。ブラックリストは、ＭｃＡｆｅｅ社によって提供されるＡｒｔｅｍｉｓ及びＡｎｔｉ−Ｖｉｒｕｓデータベース、並びにローカル・ネットワーク内にローカルに維持されたブラックリストを含む多数のソースによって提供されてもよい。この実施形態では、プログラム・ファイルが、内部又は外部ブラックリストのどれかに見つかった場合、プログラム・ファイルは、プログラム・ファイルを識別する中央非信頼ソフトウェア・インベントリ２３２を更新することにより、信頼できないと分類される。非信頼プログラム・ファイル情報は、ホスト３００にプッシュされてローカル非信頼ソフトウェア・インベントリ３３０が更新されてもよい。

図６に移ると、図６は、図４のステップ４３０に対応する信頼判定フロー６００の代替の実施形態を示す。これは、ソフトウェア・インベントリ内の各プログラム・ファイルについて実行されてもよい。フローは、ステップ６２０で始まり、現在のプログラム・ファイルが評価されて、変化したかどうかが判定される。プログラム・ファイルの現在の状態が、前の状態から変化していない場合は、プログラム・ファイルの信頼性状態は、信頼できるとして定義され、フローが終了して、中央非信頼ソフトウェア・インベントリ２３２が、プログラム・ファイルを識別するように更新されない。しかしながら、プログラム・ファイルの現在の状態が前の状態から変化した場合は、プログラム・ファイルは、非信頼状態を有する。既存の変更追跡製品（例えば、ＭｃＡｆｅｅ（登録商標）Ｃｈａｎｇｅ Ｃｏｎｔｒｏｌソフトウェア、ＭｃＡｆｅｅ（登録商標）Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌソフトウェア、ＭｃＡｆｅｅ（登録商標）ｅＰｏｌｉｃｙ Ｏｒｃｈｅｓｔｒａｔｏｒソフトウェア、ＭｃＡｆｅｅ（登録商標）Ｐｏｌｉｃｙ Ａｕｄｉｔｏｒソフトウェア、オレゴン州ポートランドのＴｒｉｐｗｉｒｅ社によって製造されたＴｒｉｐｗｉｒｅ（登録商標）ソフトウェアなど）を使用して、プログラム・ファイルの変更データを調べて変更が起きたかどうかを判定してもよい。一例では、変更レコードは、中央サーバ２００で集中的に総計されてもよく、ＭｃＡｆｅｅ（登録商標）ｅＰＯソフトウェアが、プログラム・ファイルが変化したかどうかを判定してもよい。

図６において、ステップ６２０で、プログラム・ファイルが非信頼状態を有すると判定された場合、フローはステップ６３０に進んでもよく、プログラム・ファイルが評価されて、図５のステップ５３０に関連して本明細書で前に述べたように、プログラム・ファイルをその非信頼状態から信頼状態に昇格させることができる既定条件が存在するかどうかが判断されてもよい。１つ又は複数の既定条件によって、プログラム・ファイルが信頼状態に昇格する場合は、フローは終了し、中央非信頼ソフトウェア・インベントリ２３２が更新されない。しかしながら、既定条件がプログラム・ファイルに当てはまらない場合は、非信頼状態が持続し、プログラム・ファイルは、ステップ６４０で、プログラム・ファイルを識別する中央非信頼ソフトウェア・インベントリ２３２を更新することによって、信頼できないとして分類されてもよい。

別の実施形態では、図５又は図６の信頼判定フローは、以前に信頼できないと分類されたプログラム・ファイルを信頼できると定義するための追加の論理（図示せず）を含んでもよい。プログラム・ファイルが、図５と図６の信頼判定フロー５００又は６００のそれぞれから信頼できると定義された場合、プログラム・ファイルの信頼状態が以前に判定された非信頼状態から変化したものであるかどうかを判定する追加論理が、提供されてもよい。そのような場合、中央非信頼ソフトウェア・インベントリ２３２は、プログラム・ファイルエントリの状態が信頼できないから信頼できるに変更された場合に、そのプログラム・ファイルエントリを除去するか適切にマークするように更新されてもよい。更に、任意のそのような更新をホスト３００にプッシュして、ローカル非信頼ソフトウェア・インベントリ３３０を更新してもよい。この実施形態により、以前に信頼できないと分類されたプログラム・ファイル（例えば、内部ホワイトリスト内で更新されておらず、グローバル／外部ホワイトリストに知られていない新しい内部プログラム・ファイルなど）を、新しいプログラム・ファイルを識別するために内部ホワイトリスト又は外部ホワイトリストの一方が更新された後で、信頼できると再分類することができる。

プログラム・ファイルを列挙し、信頼性状態を判定し、それらのプログラム・ファイルを分類する代替の実施態様は、容易に明らかになる。本明細書で前に示され述べられた幾つかの実施形態は、ホスト３００などのネットワーク内の各ホスト上で実行可能ソフトウェアのインベントリを列挙し、ソフトウェア・インベントリを中央サーバ２００にプッシュし、インベントリ内の各プログラム・ファイルと関連付けられた信頼性状態を判定し、それに応じて中央非信頼ソフトウェア・インベントリ２３２を更新し、次に非信頼ソフトウェア・インベントリ更新を適切なホストにプッシュしてローカル非信頼ソフトウェア・インベントリ３３０内にローカルに維持されることに言及している。しかしながら、代替の実施形態では、ソフトウェア・プログラム・ファイルの信頼判定及び分類が各ホストによってローカルに行なわれてもよく、得られた情報が別の場所（例えば、中央非信頼ソフトウェア・インベントリ２３２など）にプッシュされ、かつ／又はローカル（例えば、ローカル非信頼ソフトウェア・インベントリ３３０など）に維持されてもよい。

ソフトウェア・プログラム・ファイルの信頼性状態をローカルに判定し、次にプログラム・ファイルを適切に分類することは、ホワイトリスト評価、ブラックリスト評価、状態変更評価、又は任意の他の適切な信頼評価技術によって行なわれてもよい。そのような実施形態では、実行可能ソフトウェアのインベントリは、例えば、ＭｃＡｆｅｅ（登録商標）ソフトウェア（例えば、Ｐｏｌｉｃｙ Ａｕｄｉｔｏｒ、Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌ、又はＣｈａｎｇｅ Ｃｏｎｔｒｏｌ）によって列挙されてもよい。図５に示されたようなホワイトリスト評価を行なうとき、ホストは、ローカル・ネットワーク上の内部ホワイトリスト及び／又はインターネットなどの別のネットワークを介してアクセス可能な外部ホワイトリストにアクセスしてもよい。図６に示されたように、プログラム・ファイル状態変更評価は、プログラム・ファイルの現在と以前の変化状態を評価することによってローカルに行なわれてもよい。例えば、ＭｃＡｆｅｅ（登録商標）Ｃｈａｎｇｅ Ｃｏｎｔｒｏｌソフトウェアは、一連の変更レコードがホスト上にローカルに維持されることを可能にし、この変更レコードを評価して、特定のホスト上のプログラム・ファイルのどれかが変化したかどうかを判定することができる。更に、この開示の広い範囲により、例えば、ソフトウェア・プログラム・ファイルのホワイトリスト評価と状態変更評価の両方を実行すること、及び／又はソフトウェア・プログラム・ファイルのブラックリスト評価を実行することを含む多数の他の技術を使用して、ソフトウェア・プログラム・ファイルを信頼できると分類すべきかどうかを判定することができる。

１つ又は複数の非信頼ソフトウェア・インベントリは、この開示による様々な形態で適切に構成されてもよい。例えば、非信頼ソフトウェア・インベントリは、個別のホストのなか（例えば、非信頼ソフトウェア・インベントリ３３０）だけ、別の場所のなか（例えば、中央非信頼ソフトウェア・インベントリ２３２）だけ、又はこれらの何らかの組み合わせの中に常駐してもよい。一実施形態では、ローカル非信頼ソフトウェア・インベントリ３３０は、ホスト３００上に見つかった非信頼プログラム・ファイルを識別するエントリを含んでもよいが、中央非信頼ソフトウェア・インベントリ２３２は、ネットワーク内の複数のホスト上に見つかった非信頼プログラム・ファイルへのエントリを含んでもよい。中央非信頼ソフトウェア・インベントリ２３２の１つの代表的な実施形態は、ホスト名に対応する１つの列と、非信頼プログラム・ファイルのプログラムパスに対応する別の列とを有するデータベース表形式を含む。ローカル非信頼ソフトウェア・インベントリ３３０は、類似の形式を有してもよく、例えば、プログラム・ファイル・パスエントリだけを含むように単純化されてもよい。

図４から図６に関連して示し述べた列挙、信頼判定及び分類の実施形態は、ソフトウェア・インベントリを中央サーバ２００に常にフィードすることによって、又はバッチ処理を所定の時間間隔で使用することによって実施されてもよい。バッチ処理の実施形態では、バッチ処理間の時間ウィンドウにより、非信頼ソフトウェア・インベントリ３３０にまだ追加されていないボットが、ネットワークにアクセスして伝搬し、かつ／又は悪意のあるアクティビティを実行することができることがある。しかしながら、幾つかの企業では、この手法は、所定の時間間隔が重要でないか又は代替の手法が正当で必要な企業活動を妨げることがあるので、望ましい場合がある。しかしながら、別の実施形態は、これらの時間ウィンドウを閉じ、同時にバッチ処理を使用して非信頼ソフトウェア・インベントリ３３０を更新することで実現されてもよい。

この代替の実施形態では、非信頼ソフトウェア・インベントリではなく、信頼ソフトウェア・インベントリが作成され維持されてもよい。ネットワーク・アクセス試行と関連付けられたプログラム・ファイルを評価して、各プログラム・ファイルが、信頼ソフトウェア・インベントリ上に識別されるかどうかを判定してもよい。プログラム・ファイルが全て、信頼ソフトウェア・インベントリで識別されている場合は、ネットワーク・アクセスは許可されてもよい。しかしながら、プログラム・ファイルのどれも信頼ソフトウェア・インベントリで識別されない場合は、本明細書で更に述べるように、ネットワーク・アクセスは、阻止されるか選択的に許可されることがある。信頼ソフトウェア・インベントリは、集中的かつ／又はローカルに維持されてもよく、一実施形態では、ローカル信頼ソフトウェア・インベントリは、対応するホスト上の信頼プログラム・ファイルのみ、ネットワーク内のホストからの全ての信頼プログラム・ファイル、及び／又はネットワーク管理者又は他の権限あるユーザによって判定された他の信頼プログラム・ファイルを含むように構成されてもよい。

図７に移ると、単純化されたフローチャートは、ホスト３００上の実行ソフトウェア・プロセス３４５などのホスト上のソフトウェア・プロセスと関連付けられたネットワーク・アクセス試行（即ち、インバウンド又はアウトバウンド）の遮断、阻止、及びログ記録アクティビティの保護フロー７００を示す。一例では、保護フロー７００は、少なくとも部分的にホスト３００のローカル保護モジュール３１０として実現されてもよい。参照し易くするため、保護フロー７００は、最初に、ホスト３００上のソフトウェア・プロセス３４５からホスト３００に接続されたネットワークへのアウトバウンド・ネットワーク・アクセス試行に関して記述される。

フローは、ステップ７１０で始まり、ローカル保護モジュール３１０は、ソフトウェア・プロセス３４５によるアウトバウンド・ネットワーク・アクセス試行を遮断する。一実施形態では、実行可能ソフトウェア３４０からのプロセスは、ＮＤＩＳドライバ・スタックを使用して、ホスト３００のＮＩＣ装置３７０を介してネットワークにアクセスする。これにより、ソフトウェア・プロセス３４５は、ＮＤＩＳドライバ・スタックを介して電子データを送信することによってネットワークへのアクセスを試みてもよい。接続が、インターネット・プロトコル・スイートを使用している場合、ＴＣＰ／ＩＰ３５０は、電子データをパケットに分解し、要求された宛先アドレスを提供する。あるいは、接続は、他のプロトコル３６０（例えば、インターネットワーク・パケット交換（ＩＰＸ）、ＮｅｔＢＩＯＳ拡張ユーザインタフェース（ＮｅｔＢＥＵＩ）など）を使用して送信する電子データを作成してもよい。発信パケットを作成した後で、ローカル保護モジュール３１０は、任意のタイプのネットワーク・アクセスの試み（例えば、ドメインネームサービス（ＤＮＳ）ホスト名を参照する試み、リモートホストに接続する試み、ネットワークに既に接続されていたソケットに書き込む試み、など）でよいパケットを遮断する。

発信パケットが遮断された後、フローはステップ７２０に進み、実行ソフトウェア・プロセス３４５と関連付けられた遮断パケットにどのプログラム・ファイル（例えば、実行可能ファイル、ライブラリ・モジュール、オブジェクト・ファイル、他の実行可能モジュール、スクリプト・ファイル、インタープリタ・ファイルなど）が対応するかをオペレーティング・システムに照会してもよい。この例では、遮断パケットは、実行ソフトウェア・プロセス３４５にマッピングされ、プロセス３４５にロードされる実行可能ファイルと１つ又は複数のライブラリ・モジュールにマッピングされることがある。ステップ７２０で、オペレーティング・シスタム・カーネルは、プロセス・トラフィック・マッピング要素３６５を維持し、そのようなマッピング情報をローカル保護モジュール３１０に提供する。次に、フローは、ステップ７３０に進み、プロセス３４５からの遮断パケットに対応する１つ又は複数のプログラム・ファイルが信頼できるかどうかが照会される。一例では、ローカル保護モジュール３１０は、制御フロー３１８を介して、プログラム・ファイルに関する情報をソフトウェア管理モジュール３２０に照会してもよい。次に、ソフトウェア管理モジュール３２０は、ローカル非信頼ソフトウェア・インベントリ３３０にアクセスして、プログラム・ファイルが信頼できないと分類されるか信頼できると分類されるかを判定し、次にその情報を制御フロー３１８を介してローカル保護モジュール３１０に返してもよい。

ステップ７３０で、プログラム・ファイルのどれかが信頼できないと分類された（即ち、プログラム・ファイルの１つ又は複数が、ローカル非信頼ソフトウェア・インベントリ３３０上に見つかった）場合、フローはステップ７４０に進んで、ログ記録が有効かどうかを判断する。ステップ７４０で、ログ記録が有効である場合、フローはステップ７５０に進み、ログ記録のためのイベント（即ち、ネットワーク・アクセス試行）を発生させる。例えば、イベント・データ（例えば、ネットワーク・アクセス試行及びその関連プログラム・ファイルに関する情報）が、イベント・フロー３１６を介してソフトウェア管理モジュール３２０に送信されてもよく、次に、ソフトウェア管理モジュール３２０は、イベント・データをローカルにログ記録してもよく、イベント・データを、例えば中央サーバ２００などのログ記録するための別の場所に、イベント・フロー３２６を介して送信してもよい。例示的な実施形態では、中央サーバ２００の管理保護モジュール２２０は、イベント・データをログ・イベント・データベース２３１などのメモリ要素に記憶するように適応されてもよい。ログ・イベント・データベース２３１に記憶されるイベント・データの例には、遮断パケットに関連付けられたプログラム・ファイルの識別及び／又はプログラムパス、イベントが生じたホストの識別、ネットワーク・アクセス試行の日時スタンプ、ネットワーク・アクセス試行のタイプ、ネットワーク・アクセス試行の宛先及び／又はソースアドレス、ネットワーク・アクセス試行と関連付けられたポート番号などが挙げられる。管理保護モジュール２２０は、また、管理コンソール２１０又は他の報告機構を介してログ・イベント・データベース２３１に対するアクセスを提供してもよい。

次に、ステップ７５０でログ記録するイベントを生成した後、又はステップ７４０でログ記録が有効でない場合、フローはステップ７６０に進んで取り締まりが有効かどうか判定される。取り締まりが有効でない場合、フローはステップ７９０に進み、ソフトウェア・プロセス３４５のネットワークへのアクセスが許可され、遮断パケットが、ＮＩＣ装置３７０に渡される。しかしながら、ステップ７６０で取り締まりが有効である場合は、ステップ７７０でポリシーが評価されて、構成ポリシーが、プログラム・ファイルの非信頼状態を覆し、ソフトウェア・プロセス３４５と関連付けられたネットワーク・アクセス又は選択的ネットワーク・アクセスが許可されるかどうか判定される。

一実施形態では、ポリシー構成は、ネットワーク管理者によって巧妙に作成されてもよく、そのようなポリシーは、ホスト３００などの各ホストにプッシュされてもよい。例えば、中央サーバ２００のポリシー・モジュール２３０は、管理者又は他の権限あるユーザが管理コンソール２１０を介してポリシー構成を巧妙に作成し、そのようなポリシーをポリシー・データベース２３５に記憶することを可能にしてもよい。次に、管理保護モジュール２２０は、ポリシー更新フロー３２２を介して、任意の関連ポリシー構成をホスト３００のソフトウェア管理モジュール３２０にプッシュしてもよい。ソフトウェア管理モジュール３２０は、更に、ポリシー更新フロー３１２により、ポリシー構成をローカル保護モジュール３１０にプッシュしてもよい。あるいは、ポリシー構成は、例えばホスト３００のディスクドライブに記憶されてもよく、ローカル保護モジュール３１０は、評価される特定のプロセスの関連ポリシーをソフトウェア管理モジュール３２０に照会してもよい。

ポリシー構成は、特定のネットワーク所有者によって必要に応じて実施されてもよい。幾つかの例示的な実施形態では、ポリシー構成は、インバウンド及びアウトバウンド・ネットワーク・アクセスを全て阻止する、インバウンド・ネットワーク・アクセスを全て阻止しアウトバウンド・ネットワーク・アクセスを許可する、インバウンド・ネットワーク・アクセスを許可しアウトバウンド・ネットワーク・アクセスを阻止するなど、１つ又は複数の広範囲にわたる制限を含んでもよい。また、ローカル・ネットワークへのアウトバウンド・ネットワーク・アクセスを阻止するがインターネットへのアウトバウンド・ネットワーク・アクセスを許可する、又はソースアドレスの指定サブネットからのインバウンド・ネットワーク・アクセスを許可しかつ／又は宛先アドレスの指定サブネットへのアウトバウンド・ネットワーク・アクセスを許可するなど、より具体的な戦略が使用されてもよい。最終的に、指定されたインバウンド及び／又はアウトバウンド・ネットワーク接続（例えば、ドメインネームサービス（ＤＮＳ）、簡易メール転送プロトコル（ＳＭＴＰ）、インターネット・リレー・チャット（ＩＲＣ）など）を阻止するなど、更に大雑把な戦略が使用されてもよい。これらの例のポリシー構成は、ネットワーク・アクセス制限の機能を示す説明のためのものであり、インバウンド及び／若しくはアウトバウンド・ネットワーク・アクセス又はこれらの任意の組み合わせを制限する任意の他のポリシー構成を含むように意図される。

非信頼プログラム・ファイルのための特別なネットワーク・レベル・ポリシーが巧妙に作成されることもある。例えば、ポリシーは、非信頼プログラム・ファイルと関連付けられたネットワーク・アクセス試行を、セカンダリ・サーバなどの別の計算装置に転送するように巧妙に作成されることがある。一例では、この転送を使用するとき、非信頼プログラム・ファイルと関連付けられた潜在的に悪意のあるネットワーク・アクセス試行が、追加のファイアウォール、フィルタ、アンチスパム／アンチウイルス・ゲートウェイ、プロキシなどを介して強制される可能性がある。別の例では、セカンダリ・サーバは、ネットワーク接続を受け取ったときに１つ又は複数の所定のコマンドで応答するように構成されてもよい。幾つかのボットは、特定のコマンドを受け取ると自滅するように設計されており、セカンダリ・サーバは、ネットワーク接続にそのようなコマンドで応答するように構成されてもよく、それにより、セカンダリ・サーバに転送されたボットが破壊される。

特定のポリシー構成は、非信頼ソフトウェアの伝搬及び潜在的に悪意のあるアクティビティを防ぐ必要性や、必要な企業活動を行なう必要性など、競合する関心の間で平衡がとられることがある。例えば、ホスト・サブネットとサーバ・サブネットを有するネットワークでは、ポリシーは、非信頼プログラム・ファイルと関連付けられたソフトウェア・プロセスが、ホスト・サブネットではなくサーバ・サブネットだけにアクセスできるように構成されてもよい。これは、悪意のあるソフトウェアがネットワーク内の他のホストに伝搬するのを防ぐことができ、同時にホストがセキュアなサーバ・サブネットに中断なしにアクセスすることを可能にするので望ましいことがある。別のポリシーは、信頼できないプログラム・ファイルと関連付けられたソフトウェア・プロセスが、既知のサブネット・ホスティング・ジョブ・クリティカル・サービスを除いて、インターネットへアクセスするのを阻止してもよい。したがって、選択的なネットワーク・アクセスを許可するポリシーを巧妙に作成することにより、様々な阻止オプションを使用することができる。

図７のステップ７７０に戻ると、実行ソフトウェア・プロセス３４５に対応する１つ又は複数の非信頼プログラム・ファイルによる選択的なネットワーク・アクセスを許可するポリシーが巧妙に作成され、かつ遮断されたパケットが、特定のポリシー要件に適合する場合（例えば、パケットが、非信頼プログラム・ファイルに適用されるポリシーによりアドレスの許可されたサブネットの範囲内にある宛先アドレスを有する場合、など）は、フローは、ステップ７９０に進み、ソフトウェア・プロセス３４５が、ネットワーク・アクセスを許可され、パケットがＮＩＣ装置３７０に渡される。しかしながら、ポリシーが、１つ又は複数のプログラム・ファイルの非信頼状態を覆さない場合（即ち、ポリシーがネットワーク・アクセスを許可しないか、ポリシーが適用可能でない場合）は、フローはステップ７８０に進み、ソフトウェア・プロセス３４５は、ネットワーク・アクセスから阻止される。一例では、阻止は、ＴＣＰ接続コールを失敗させエラーコードをソフトウェア・プロセス３４５に返すことによって行われ、それにより、遮断パケットが、ＮＩＣ装置３７０に渡されるのが防止される。

ステップ７３０に再び関連して、プログラム・ファイルが、信頼できると分類された場合（即ち、ローカル非信頼ソフトウェア・インベントリ３３０にプログラム・ファイルが見つからない場合）は、フローがステップ７６０に進んで、取り締まりが有効かどうか判断される。取り締まりが有効でない場合、フローはステップ７９０に進み、ソフトウェア・プロセス３４５が、ネットワーク・アクセスを許可され、遮断パケットが、ＮＩＣ装置３７０に渡される。しかしながら、ステップ７６０で取り締まりが有効である場合は、ステップ７７０で、ポリシーが評価されて、構成ポリシーが１つ又は複数のプログラム・ファイルの信頼状態を覆すかどうか判断されてもよい。例えば、非信頼プログラム・ファイルが、以前に遮断されており、ポリシーが、全てのアウトバウンド・ネットワーク・アクセス試行に適用される何らかのタイプの阻止を提供した場合は、後のネットワーク・アクセス試行と関連付けられた信頼できるプログラム・ファイルが評価され、そのポリシーによってネットワーク・アクセスから阻止される可能性がある。したがって、ポリシーが、１つ又は複数のプログラム・ファイルの信頼状態を覆す（即ち、ポリシーが、ネットワーク・アクセスを許可しない）場合は、フローはステップ７８０に進み、ソフトウェア・プロセス３４５が、ネットワーク・アクセスから阻止される。しかしながら、ステップ７７０で信頼状態がポリシーによって覆されない（即ち、ポリシーが、ネットワーク・アクセスを許可するか、ポリシーが適用できない）場合、フローはステップ７９０に進み、ソフトウェア・プロセス３４５は、ネットワーク・アクセスが許可され、遮断パケットが、ＮＩＣ装置３７０に渡される。

図７の保護フロー７００は、また、ホスト３００に対するインバウンド・ネットワーク・アクセス試行の遮断、阻止及びログ記録アクティビティに使用されるフローを表わす。ステップ７１０で、ローカル保護モジュール３１０は、ＮＩＣ装置３７０からのインバウンド・ネットワーク・アクセス試行を遮断する。インバウンド・ネットワーク・アクセス試行は、例えばＴＣＰリスン又はアクセプト・コールであり、ソフトウェア・プロセス３４５などのホスト３００上の実行ソフトウェア・プロセスと関連付けられることがある。着信遮断パケットは、ネットワーク・アクセス試行の発信遮断パケットに関して本明細書で前に述べたステップ７２０〜７７０で評価される。ステップ７２０から７７０のフローがステップ７９０に進んだ場合は、着信遮断パケットが、ホスト３００にアクセスすることを許可される。しかしながら、フローがステップ７８０に進んだ場合、着信遮断パケットは、ホスト３００へのアクセスが阻止される。一例では、阻止は、リスン又はアクセプト・コールを失敗させ、リスン又はアクセプトＡＰＩの発呼者にエラーコードを返すことによって行われる。更に、本明細書で前に述べたように、インバウンド・ネットワーク・アクセス試行の多数のポリシー構成が可能である。一例では、ステップ７７０で、１つ又は複数の非信頼プログラム・ファイルと関連付けられた特定のインバウンド・ネットワーク・アクセス試行を許可するポリシーが巧妙に作成され、着信パケットが、その特定のポリシー要件に適合する（例えば、パケットが、非信頼プログラム・ファイルに適用されるポリシーによりアドレスの許可されたサブネットの範囲内にあるソースアドレスを有する）と判定された場合、フローはステップ７９０に進み、着信遮断パケットが、ホスト３００へのアクセスを許可される。別の例では、ポリシーが、以前のネットワーク・アクセス試行（即ち、インバウンド又はアウトバウンド）に既に適用されており、後のネットワーク・アクセス試行に適用される何らかのタイプの阻止を提供した場合、後のインバウンド・ネットワーク・アクセス試行と関連付けられたプロセスは、対応するプログラム・ファイルが全て信頼状態を有する場合でも、そのポリシーによりホストへのアクセス又は選択的に許可されたアクセスが阻止されることがある。

図８に移ると、図８は、悪意のあるソフトウェアからローカル保護するシステムの別の実施形態が実現されることがある、計算装置又はホスト８００の別の実施形態の概略図と中央サーバ２００のブロック図とを示す。ホスト８００は、図１のホスト１２０の一実施形態のより詳細な例である。ホスト８００は、例えばプログラム・ファイル１〜ｎなどの１組の実行可能ソフトウェア８４０を含む。ホスト８００内のローカル・ネットワーク保護構成要素は、ネットワーク・フック８１０、ソフトウェア管理モジュール８２０、ローカル非信頼ソフトウェア・インベントリ８３０、及びソフトウェア・プログラム・インベントリ・フィード８３５を含んでもよい。参照し易くするため、実行可能ソフトウェア８４０は、ホスト８００上のユーザ空間内に示されるが、ホスト８００上のディスクドライブなどのメモリ要素に記憶されてもよい。

ソフトウェア・プロセス８４５などの任意の現在の実行ソフトウェア・プロセスに加えて、ソフトウェア管理モジュール８２０、ローカル非信頼ソフトウェア・インベントリ８３０、及びソフトウェア・プログラム・インベントリ・フィード８３５が、ホスト８００のユーザ空間内に常駐してもよい。図８の実施形態で示されたように、プログラム・ファイルが実行され、実行ソフトウェア・プロセス８４５を作成するときは、実行ソフトウェア・プロセス８４５によってロードされる他のライブラリ・モジュールに加えて、Ｗｉｎｄｏｗｓ（登録商標） Ｓｏｃｋｅｔｓ ＡＰＩ（Ｗｉｎｓｏｃｋ）ライブラリ８１５が、従属物としてソフトウェア・プロセス８４５にロードされ、ネットワーク・フック８１０が、従属物としてＷｉｎｓｏｃｋライブラリ８１５にロードされてもよい。ネットワーク・フック８１０を実施するには、ＭｃＡｆｅｅ社によって製造されたＨｏｓｔ Ｉｎｔｒｕｓｉｏｎ Ｐｒｅｖｅｎｔｉｏｎ Ｓｙｓｔｅｍ（ＨＩＰＳ）などの既存のセキュリティ技術が使用されてもよい。

ソフトウェア管理モジュール８２０と中央サーバ２００との間に、ポリシー更新フロー８２２、非信頼ソフトウェア更新フロー８２４及びイベント・フロー８２６を含むデータ・フローが示される。また、ソフトウェア管理モジュール８２０とネットワーク・フック８１０との間に、ポリシー更新フロー８１２、制御フロー８１８及びイベント・フロー８１６を含むデータ及び制御フローが示される。

ホスト８００は、ネットワーク・インタフェース・カード（ＮＩＣ）装置８７０、プロセッサ８８０、メモリ要素８９０などのハードウェア構成要素を含んでもよい。ホスト８００のカーネル空間は、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）８５０や他のプロトコル８６０などの伝送プロトコルを含んでもよい。図８には、図３のホスト３００に関して述べたような追加のハードウェア及びソフトウェアは示されていない。

ネットワーク・フック８１０とソフトウェア管理モジュール８２０は、ホスト８００上のソフトウェア・プロセス８４５などの実行可能ソフトウェア８４０のプログラム・ファイルからのプロセスと関連付けられたネットワーク・アクセス試行の遮断、阻止及びログ記録アクティビティを少なくとも部分的に提供するように構成されてもよい。遮断、阻止及びログ記録アクティビティと関連した情報は、特定の場所（例えば、中央サーバ２００、ログ・イベント・データベース２３１など）にプッシュされ、単にローカルに記憶されるかアーカイブされ、かつ／又は任意の適切な形式で適切に表示され（例えば、管理コンソール２１０などによって）てもよい。１つ又は複数のそのような遮断、阻止及びログ記録アクティビティと関連したセキュリティ技術は、図３に関連して本明細書で前に述べたような要素を含んでもよく、ＭｃＡｆｅｅ（登録商標）ＨＩＰＳソフトウェアを含んでもよい。したがって、本明細書で使用される用語「ネットワーク・フック」及び「ソフトウェア管理モジュール」の広い範囲に、任意のそのような構成要素が含まれてもよい。ローカル非信頼ソフトウェア・インベントリ８３０は、実行可能ソフトウェア８４０のプログラム・ファイルの信頼分類など、電子データの阻止及びログ記録と関連した情報を含んでもよく、これらの要素は、ネットワーク・フック８１０及びソフトウェア管理モジュール８２０と容易に協力し、連係し、その他相互作用することができる。

図９に移ると、単純化されたフローチャートは、ホスト８００上の実行ソフトウェア・プロセス８４５などのホスト上のソフトウェア・プロセスと関連付けられたネットワーク・アクセス試行（即ち、インバウンド又はアウトバウンド）の遮断、阻止、及びログ記録アクティビティの保護フロー９００を示す。一例では、保護フロー９００は、ネットワーク・フック８１０によって部分的に実行され、ホスト８００のソフトウェア管理モジュール８２０によって部分的に実行されてもよい。参照し易くするために、最初に、保護フロー９００は、ホスト８００上のソフトウェア・プロセス８４５からホスト８００に接続されたネットワークへのアウトバウンド・ネットワーク・アクセス試行について述べられる。

フローはステップ９１０で始まり、ネットワーク・フック８１０が、ソフトウェア・プロセス８４５からのＡＰＩアウトバウンド・ネットワーク・アクセス試行（例えば、接続ＡＰＩ、送信ＡＰＩなど）を遮断する。ネットワーク・フック８１０が、Ｗｉｎｓｏｃｋライブラリ８１５上の従属物としてソフトウェア・プロセス８４５にロードされるので、ネットワーク・フック８１０は、ＴＣＰ／ＩＰプロトコルスタック８５０とインタフェースするＷｉｎｓｏｃｋライブラリ８１５に渡される前にＡＰＩネットワーク・アクセス試行を遮断することができる。ネットワーク・アクセス試行は、任意のタイプのネットワーク・アクセス（例えば、ドメインネームサービス（ＤＮＳ）ホスト名を参照する試み、リモートホストに接続する試み、ネットワークに既に接続されているソケットに書き込む試みなど）でよい。ＡＰＩが遮断された後で、フローはステップ９２０に進み、どのプログラム・ファイル（例えば、実行可能ファイル、ライブラリ・モジュール、オブジェクト・ファイル、他の実行可能モジュール、スクリプト・ファイル、インタープリタ・ファイルなど）が、実行ソフトウェア・プロセス８４５と関連付けられるか判定する。この例では、遮断されたＡＰＩは、実行ソフトウェア・プロセス８４５にマッピングされ、プロセス８４５にロードされた実行可能ファイル及び１つ又は複数のライブラリ・モジュールにマッピングされてもよい。例示的な実施形態では、ソフトウェア管理モジュール８２０は、どのプログラム・ファイルが実行ソフトウェア・プロセス８４５にマッピングされ、遮断ＡＰＩにマッピングされたかに関して、制御フロー８１８を介してネットワーク・フック８１０から照会される。ソフトウェア管理モジュール８２０は、オペレーティング・システムＡＰＩを使用してそのようなマッピング情報を得ることがある。

プログラム・ファイルが識別された後で、フローは、図７の保護フロー７００のステップ７３０〜７９０と類似していることがあるステップ９３０〜９９０に進む。ステップ９３０で、ローカル非信頼ソフトウェア・インベントリ８３０上に、ソフトウェア・プロセス８４５に対応するプログラム・ファイルが見つかったかどうかが照会される。一例では、ソフトウェア管理モジュール８２０は、ローカル非信頼ソフトウェア・インベントリ８３０にアクセスして、プログラム・ファイルが信頼できないと分類されるか信頼できると分類されるか判定してもよい。ステップ９３０で、プログラム・ファイルのどれかが信頼できないと分類された（即ち、プログラム・ファイルの１つ又は複数がローカル非信頼ソフトウェア・インベントリ８３０上に見つかった）場合、フローはステップ９４０に進んで、ログ記録が有効かどうか判定する。ログ記録が有効である場合は、フローはステップ９５０に進んで、図７に関連して本明細書で前に述べたように、ログ記録のためのイベント（即ち、ネットワーク・アクセス試行）を発生させる。

次に、ステップ９５０でログ記録のためのイベントが生成された後、フローがステップ９６０に進み、取り締まりが有効かどうか判定する。取り締まりが有効でない場合、ソフトウェア・マネージャ８２０は、この情報を制御フロー８１８を介してネットワーク・フック８１０に渡してもよい。次に、フローはステップ９９０に進み、ソフトウェア・プロセス８４５が、ＡＰＩをＷｉｎｓｏｃｋ８１５に渡すことによってネットワークへのアクセスを許可される。しかしながら、ステップ９６０で取り締まりが有効である場合は、図７に関連して本明細書で前に述べたように、ステップ９７０でポリシーが評価されて、構成ポリシーが、１つ又は複数の非信頼プログラム・ファイルの非信頼状態を覆すかどうか判定されてもよい。一実施形態では、ポリシー評価は、ソフトウェア管理モジュール８２０内で行われてもよく、その結果が、制御フロー８１８を介してネットワーク・フック８１０に渡されてもよい。

ポリシー構成は、例えば中央サーバ２００の管理保護モジュール２２０を介して、ネットワーク管理者又は他の権限あるユーザによって巧妙に作成されてもよい。管理保護モジュール２２０は、ポリシー更新フロー８２２を介して、任意の関連したポリシー構成を、ホスト８００のソフトウェア管理モジュール８２０にプッシュしてもよい。ポリシーが、ソフトウェア・プロセス８４５に対応する１つ又は複数の非信頼プログラム・ファイルによる選択的ネットワーク・アクセスを許可するように巧妙に作成されており、かつＡＰＩが、特定のポリシー要件に適合する（例えば、ＡＰＩネットワーク・アクセス試行が、ポリシーにしたがってアドレスの許可されたサブネットの範囲内にある宛先アドレスを含む）場合、ソフトウェア管理モジュール８２０は、そのような情報を制御フロー８１８を介してネットワーク・フック８１０に返してもよい。次に、フローはステップ９９０に進み、ＡＰＩがＷｉｎｓｏｃｋ８１５に渡され、ソフトウェア・プロセス８４５は、ネットワークへのアクセスが許可される。しかしながら、ステップ９７０でポリシーがネットワーク・アクセスを許可しない場合、又は適用可能なポリシーが存在しない場合は、ソフトウェア管理モジュール８２０は、そのような情報を制御フロー８１８を介してネットワーク・フック８１０に返し、フローがステップ９８０に進み、ＡＰＩは、Ｗｉｎｓｏｃｋ ８１５に渡されない。代わりに、ネットワーク・フック８１０が、エラー状態をソフトウェア・プロセス８４５に返し、それにより、ネットワーク・アクセスが阻止されてもよい。

ステップ９３０に再び関連して、プログラム・ファイルが、信頼できるとして分類された（即ち、プログラム・ファイルが、ローカル非信頼ソフトウェア・インベントリ８３０上に見つからない）場合は、フローはステップ９６０に進み、取り締まりが有効かどうか判断する。取り締まりが有効でない場合、フローはステップ９９０に進み、ＡＰＩがＷｉｎｓｏｃｋ ８１５に渡され、ソフトウェア・プロセス８４５は、ネットワークへのアクセスを許可される。しかしながら、ステップ９６０で取り締まりが有効である場合は、図７に関連して本明細書で前に述べたように、ステップ９７０でポリシーが評価されて、構成ポリシーが信頼状態を覆すかどうか判断される。ポリシーが、１つ又は複数のプログラム・ファイルの信頼状態を覆す場合、フローはステップ９８０に進み、ＡＰＩは、Ｗｉｎｓｏｃｋ ８１５に渡されない。代わりに、ネットワーク・フック８１０は、エラー状態をソフトウェア・プロセス８４５に返し、それによりネットワーク・アクセスが阻止されてもよい。しかしながら、ステップ９７０で、１つ又は複数のプログラム・ファイルの信頼状態が、ポリシーによって覆されない場合、フローはステップ９９０に進み、ＡＰＩが、Ｗｉｎｓｏｃｋ８１５に渡され、ソフトウェア・プロセス８４５は、ネットワークへのアクセスが許可される。

保護フロー９００は、また、ホスト３００へのインバウンド・ネットワーク・アクセス試行の遮断、阻止及びログ記録アクティビティに使用されるフローを表わす。ステップ９１０で、ネットワーク・フック８１０は、Ｗｉｎｓｏｃｋライブラリ８１５からＡＰＩインバウンド・ネットワーク・アクセス試行（例えば、リッスンＡＰＩ、アクセプトＡＰＩなど）を遮断する。インバウンド・ネットワーク・アクセス試行は、アウトバウンド遮断ＡＰＩに関して本明細書で前に述べたステップ９２０〜９７０で評価される。ステップ９２０〜９７０のフローがステップ９９０に進む場合、インバウンド・ネットワーク・アクセス試行は、ホスト３００へのアクセスが許可される。しかしながら、フローが、ステップ９８０に進む場合、インバウンド・ネットワーク・アクセス試行は、ホスト３００へのアクセスが阻止される。一例では、阻止は、リスン又はアクセプト・コールを拒絶し、リスン又はアクセプトＡＰＩの発呼者にエラーコードを返すことによって行われる。更に、図７に関して本明細書で前に述べたように、ステップ９７０で、インバウンド・ネットワーク・アクセスのポリシー構成が適用されてもよい。

図１０に移ると、図１０は、悪意のあるソフトウェアからローカル保護するシステムを実現することができる計算装置又はホスト１０００の別の実施形態の概略図と中央サーバ２００のブロック図とを示す。ホスト１０００は、図１のホスト１２０のより詳細な例である。ホスト１０００は、例えばプログラム・ファイル１〜ｎを含む１組の実行可能ソフトウェア１０４０を含んでもよい。ホスト１０００内のローカル・ネットワーク保護構成要素は、ローカル保護モジュール１０１０、ソフトウェア管理モジュール１０２０、プログラム・ファイル変更モニタ１０２５、チェックサム・キャッシュ１０３０、及びローカル信頼キャッシュ１０３５を含んでもよい。一実施形態では、チェックサム・キャッシュ１０３０とローカル信頼キャッシュ１０３５は、対応するソフトウェア・プログラム・ファイルのためのプログラム・ファイル・パスとチェックサムで構成されてもよい。ソフトウェア管理モジュール１０２０とプログラム・ファイル変更モニタ１０２５は、ホスト１０００のユーザ空間内に常駐してもよい。また、ホスト１０００のユーザ空間内には、実行可能ソフトウェア１０４０のプログラム・ファイルの１つ又は複数に対応する例示的な実行ソフトウェア・プロセス１０４５も示される。参照しやすいように、実行可能ソフトウェア１０４０は、ホスト１０００上のユーザ空間内に示されているが、ホスト１０００上のディスクドライブなどのメモリ要素内に記憶されてもよい。

ホスト１０００は、ネットワーク・インタフェース・カード（ＮＩＣ）装置１０７０、プロセッサ１０８０、メモリ要素１０９０などのハードウェア構成要素を含んでもよい。ローカル保護モジュール１０１０と、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）１０５０や他のプロトコル１０６０などの伝送プロトコルとは、ホスト１０００のカーネル空間内に常駐してもよく、図３にホスト３００と関連して示され記述された実施形態と類似の方式で、ＮＩＣ装置１０７０とインタフェースするネットワーク・ドライバ・インタフェース仕様（ＮＤＩＳ）ドライバ・スタックの一部として実現されてもよい。オペレーティング・システム・カーネルは、ソフトウェア・プロセスを実行可能ソフトウェア１０４０のその対応プログラム・ファイルにマッピングするプロセス・トラフィック・マッピング要素１０６５を提供する。

ソフトウェア管理モジュール１０２０と中央サーバ２００との間に、ポリシー更新フロー１０２２、ホワイトリスト照会データ・フロー１０２４及びイベント・フロー１０２６を含むデータ・フローが示される。また、ソフトウェア管理モジュール１０２０とローカル保護モジュール１０１０との間に、ポリシー更新フロー１０１２、制御フロー１０１８及びイベント・フロー１０１６を含むデータ及び制御フローが示される。最終的に、チェックサム・キャッシュ１０３０とローカル信頼キャッシュ１０３５は、ソフトウェア管理モジュール１０２０に対する双方向の流れを有することができ、プログラム・ファイル変更モニタ１０２５は、変更がプログラム・ファイルに行われたこと示すデータをソフトウェア管理モジュール１０２０に送る。図１０には、図３のホスト３００に関連して本明細書で前に述べた付加的なハードウェアと類似したホスト１０００の付加的なハードウェアが示されていない。

ローカル信頼キャッシュ１０３５とチェックサム・キャッシュ１０３０は、ホスト１０００のハードウェア内に、一時的記憶用のメモリのブロックとして構成されてもよい。ローカル信頼キャッシュ１０３５は、グローバル・ホワイトリストの検索、内部ホワイトリストの検索、ブラックリストの検索、プログラム・ファイル変更の評価、又はこれらの任意の組み合わせなどの信頼評価技術を使用して、信頼状態を有することが既に判定されているプログラム・ファイルを識別するエントリ（例えば、チェックサム）を含んでもよい。したがって、ローカル信頼キャッシュ１０３５内にプログラム・ファイルが見つかった場合は、その特定のプログラム・ファイルの信頼性状態を中央サーバ２００に照会しなくてもよい。チェックサム・キャッシュ１０３０は、ホスト１０００上のソフトウェア・プログラム・ファイルの以前に計算されたチェックサムを識別するエントリ（例えば、チェックサム及びプログラム・ファイル・パス）を含んでもよい。チェックサムの計算が、貴重な処理リソースを使用する可能性があるので、計算されたチェックサムは、無駄な二重のチェックサム計算を防ぐために、対応するプログラム・ファイル・パスと共にチェックサム・キャッシュ１０３０に記憶されてもよい。キャッシュ１０３５及び１０３０に記憶されたそのようなデータによって、ネットワーク・アクセス試行とソフトウェア信頼判定処理の際の検索と全体的な処理が早くなる。

プログラム・ファイルが変化したとき（例えば、新しいソフトウェア・バージョン、ソフトウェア・アップグレードなど）とき、その対応するチェックサムが変化し、したがって、チェックサム・キャッシュ１０３０が更新されなければならない。例示的な実施形態では、プログラム・ファイル変更モニタ１０２５は、ホスト１０００上のプログラム・ファイルの帯域外検査を実行し、変更されたプログラム・ファイルを示すデータ・フィードをソフトウェア管理モジュール１０２０に提供してチェックサム・キャッシュ１０３０を更新することによって、チェックサム・キャッシュ１０３０を更新することができる。ホスト１０００上のプログラム・ファイルを調べて変更が行われたかどうかを判定するには、既存の変更追跡製品（例えば、ＭｃＡｆｅｅ（登録商標）Ｃｈａｎｇｅ Ｃｏｎｔｒｏｌソフトウェア、ＭｃＡｆｅｅ（登録商標）Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌソフトウェア、ＭｃＡｆｅｅ（登録商標）ｅＰｏｌｉｃｙ Ｏｒｃｈｅｓｔｒａｔｏｒソフトウェア、ＭｃＡｆｅｅ（登録商標）Ｐｏｌｉｃｙ Ａｕｄｉｔｏｒソフトウェア、オレゴン州ポートランドのＴｒｉｐｗｉｒｅ社によって製造されたＴｒｉｐｗｉｒｅ（登録商標）ソフトウェア）が使用されてもよい。例示的な実施形態では、プログラム・ファイル変更モニタ１０２５は、ホスト１０００上のプログラム・ファイルへの変更を示す実時間データをソフトウェア管理モジュール１０２０に提供してもよい。変更されたプログラム・ファイル・データを受け取った後で、ソフトウェア管理モジュール１０２０は、変更されたプログラム・ファイルに対応するプログラム・ファイル・パスをチェックサム・キャッシュ１０３０内で探してもよく、見つかった場合に、そのプログラム・ファイル・パスと関連付けられたチェックサム・エントリを削除してもよい。チェックサム・キャッシュ１０３０とプログラム・ファイル変更モニタ１０２５は、ホスト１０００上のプログラム・ファイルのプログラム・ファイル・チェックサムを提供し、維持し、更新する一実施形態を提供するが、与えられたプログラム・ファイル・パスに置かれたプログラム・ファイルに適切なチェックサムを提供できる限り、多数の代替手法（例えば、リモート・チェックサム・モジュール、データベース実装など）を利用することができる。

ホスト１０００及び中央サーバ２００の実施形態を実現するローカル保護システムでは、非信頼ソフトウェア・インベントリ（例えば、ローカル非信頼ソフトウェア・インベントリ、中央非信頼ソフトウェア・インベントリ２３２など）は、不可欠な構成要素でないことがある。あるいは、中央サーバ２００の中央信頼キャッシュ２４５、ホスト１０００のローカル信頼キャッシュ１０３５、及びホスト１０００のチェックサム・キャッシュ１０３０は、ソフトウェア信頼判定処理の際に以前に計算され、その他判定された迅速なデータ検索に利用されてもよい。

実行可能ソフトウェア１０４０の信頼判定、阻止、遮断及びログ記録アクティビティは、例示的な実施形態では、少なくとも部分的に、中央サーバ２００の管理保護モジュール２２０とソフトウェア信頼判定モジュール２４０によって、またホスト１０００のソフトウェア管理モジュール１０２０、プログラム・ファイル変更モニタ１０２５、及びローカル保護モジュール１０１０によって提供されてもよい。そのようなアクティビティと関連した情報は、適切に描写され、特定の場所（例えば、チェックサム・キャッシュ１０３０、ローカル信頼キャッシュ１０３５、中央信頼キャッシュ２４５、ログ・イベント・データベース２３１など）に送られ、又は単に記憶若しくはアーカイブされ、かつ／又は（例えば、管理コンソール２１０などにより）任意の適切な形式で適切に表示されてもよい。１つ又は複数のそのような信頼判定、阻止、遮断及びログ記録アクティビティと関連したセキュリティ技術は、ＭｃＡｆｅｅ（登録商標）ｅＰｏｌｉｃｙ Ｏｒｃｈｅｓｔｒａｔｏｒソフトウェア、ＭｃＡｆｅｅ（登録商標）Ｈｏｓｔ Ｉｎｔｒｕｓｉｏｎ Ｐｒｅｖｅｎｔｉｏｎ Ｓｙｓｔｅｍ（ＨＩＰＳ）ソフトウェアなどのファイアウォールソフトウェア、変更追跡ソフトウェア、及び／又は他の類似のソフトウェアなどの要素を含むことができる。したがって、本明細書で使用されるような用語「管理保護モジュール」、「ソフトウェア信頼判定モジュール」、「プログラム・ファイル変更モニタ」、「ソフトウェア管理モジュール」及び「ローカル保護モジュール」の広い範囲には、任意のそのような構成要素が含まれることがある。ログ・イベント・データベース２３１、内部ホワイトリスト２３３、中央信頼キャッシュ２４５、チェックサム・キャッシュ１０３０、及びローカル信頼キャッシュ１０３５は、電子データの信頼判定、阻止、遮断及びログ記録（例えば、プログラム・ファイルの信頼判定、ソフトウェア・プロセスのネットワーク・アクセス試行など）と関連した情報を含んでもよく、これらの要素は、中央サーバ２００とホスト１０００のモジュール及び構成要素と容易に協力し、連係し、その他相互作用することができる。

図１１に移ると、単純化されたフローチャートは、ホスト１０００上の実行ソフトウェア・プロセス１０４５などのホスト上のソフトウェア・プロセスと関連付けられたネットワーク・アクセス試行（即ち、インバウンド又はアウトバウンド）の遮断、阻止及びログ記録アクティビティの保護フロー１１００を示す。一例では、保護フロー１１００は、少なくとも部分的に、ホスト１０００のローカル保護モジュール１０１０として実現されてもよい。参照し易くするため、最初に、保護フロー１１００が、ホスト１０００上のソフトウェア・プロセス１０４５からホスト１０００に接続されたネットワークへのアウトバウンド・ネットワーク・アクセス試行に関して述べられる。

フローはステップ１１１０で始まり、ローカル保護モジュール１０１０が、ソフトウェア・プロセス１０４５によってアウトバウンド・ネットワーク・アクセス試行を遮断する。一例では、実行可能ソフトウェア１０４０からのプロセスは、ＮＤＩＳドライバ・スタックを使用して、ホスト１０００のＮＩＣ装置１０７０を介してネットワークにアクセスする。したがって、ソフトウェア・プロセス１０４５は、図３と図７に関連して本明細書で前に述べたように、ＮＤＩＳドライバ・スタックを介して電子データを送信することによってネットワークにアクセスすることを試みてもよい。

発信パケットが遮断された後、フローはステップ１１２０に進み、実行ソフトウェア・プロセス１０４５からの遮断パケットにどのプログラム・ファイル（例えば、実行可能ファイル、ライブラリ・モジュール、オブジェクト・ファイル、他の実行可能モジュール、スクリプト・ファイル、インタープリタ・ファイルなど）が対応するかをオペレーティング・システムに照会してもよい。この例では、遮断パケットは、実行ソフトウェア・プロセス１０４５にマッピングされ、プロセス１０４５にロードされる実行可能ファイル及び１つ又は複数のライブラリ・モジュールにマッピングされてもよい。オペレーティング・システム・カーネルは、ステップ１１２０で、プロセス・トラフィック・マッピング要素１０６５を維持し、そのようなマッピング情報をローカル保護モジュール１０１０に提供する。

次に、フローは、１１３０で示されたステップ１１３２〜１１３６に進んでもよい。これは、ネットワーク・アクセス試行と関連付けられた各プログラム・ファイルについて実行されてもよい。ステップ１１３２では、ネットワーク・アクセス試行と関連付けられた最初のプログラム・ファイルのチェックサムが、チェックサム・キャッシュ１０３０内に見つかるかどうかの照会がされる。一実施形態では、チェックサム・キャッシュ１０３０から、最初のプログラム・ファイルのプログラム・ファイル・パスを検索する。プログラム・ファイル・パスが見つからない場合は、ステップ１１３４で最初のプログラム・ファイルのチェックサムが計算される。ステップ１１３６で、チェックサム・キャッシュ１０３０は、プログラム・ファイル・パスと新しく計算されたチェックサムで更新される。ネットワーク・アクセス試行と関連付けられた追加のプログラム・ファイルのそれぞれについて、ステップ１１３２〜１１３６が繰り返される。１つの例示的シナリオでは、ソフトウェア管理モジュール１０２０が、プログラム・ファイルが変更されたことを示すデータ・フィードをプログラム・ファイル変更モニタ１０２５から受け取ったときに、チェックサムがチェックサム・キャッシュ１０３０から以前に取り除かれている場合は、ステップ１１３２で、チェックサムが見つからないことがある。したがって、このシナリオでは、ステップ１１３４で、新しいチェックサムが、変更されたプログラム・ファイルに関して計算され、次にステップ１１３６で、チェックサム・キャッシュ１０３０に記憶される。本明細書で前に述べたように、与えられたプログラム・ファイル・パスにあるプログラム・ファイルについて適切なチェックサムを提供できる限り、任意の代替の手法を利用してチェックサムを提供することができる。

ステップ１１３２〜１１３６が、ネットワーク・アクセス試行と関連付けられた各プログラム・ファイルに行なわれた後で、フローはステップ１１４０に進む。ステップ１１４０で、ネットワーク・アクセス試行と関連付けられた全てのプログラム・ファイルが、ローカル信頼キャッシュ１０３５内に見つかるかどうかの照会がされる。見つかった場合は、各プログラム・ファイルが信頼状態を有すると以前に判定されており、フローはステップ１１７０に進み、取り締まりが有効かどうかが判定される。取り締まりが有効でない場合、フローはステップ１１９０に進み、ソフトウェア・プロセス１０４５は、ネットワーク・アクセスを許可され、遮断パケットが、ＮＩＣ装置１０７０に渡される。しかしながら、ステップ１１７０で取り締まりが有効である場合は、図７に関連して本明細書で前に述べたように、ステップ１１７５でポリシーが評価されて、ポリシーが、１つ又は複数のプログラム・ファイルの信頼状態を覆すかどうか判断されてもよい。

本明細書で前に述べたように、ポリシー構成は、ネットワーク管理者によって巧妙に作成されてもよく、そのようなポリシーは、ポリシー更新フロー１０２２を介してホスト１０００にプッシュされてもよい。ソフトウェア管理モジュール１０２０は、更に、ポリシー更新フロー１０１２により、ポリシー構成をローカル保護モジュール１０１０にプッシュしてもよい。あるいは、ポリシー構成は、例えばホスト１０００のディスクドライブ内などのメモリ要素に記憶されてもよく、ローカル保護モジュール１０１０は、評価される特定のプロセス及び／又はプログラム・ファイルの任意の関連ポリシーに関してソフトウェア管理モジュール１０２０に照会してもよい。

本明細書で前に述べたように、ポリシーが、１つ又は複数のプログラム・ファイルの信頼状態を覆す（即ち、ポリシーが、ネットワーク・アクセスを許可しない）場合は、フローはステップ１１８０に進み、ソフトウェア・プロセス１０４５は、ネットワーク・アクセスから阻止され、発信パケットが、ＮＩＣ装置１０７０に渡されない。しかしながら、ステップ１１７５で、１つ又は複数のプログラム・ファイルの信頼状態が、ポリシーによって覆されない（即ち、ポリシーがネットワーク・アクセスを許可するか、ポリシーが適用できない）場合は、フローはステップ１１９０に進み、発信パケットが、ＮＩＣ装置１０７０に渡され、ソフトウェア・プロセス１０４５は、ネットワークへのアクセスを許可される。

ステップ１１４０に再び関連して、ネットワーク・アクセス試行と関連付けられたプログラム・ファイルが、ローカル信頼キャッシュ１０３５内に見つからない場合は、フローがステップ１１４５に進み、ローカル信頼キャッシュ１０３５内に見つからなかったプログラム・ファイルの信頼判定が中央サーバ２００に照会される。これは、図１２に関連して本明細書で更に詳しく示され説明される。ローカル信頼キャッシュ１１３５内に見つからなかった各プログラム・ファイルの信頼性状態が、中央サーバ２００から返された後で、フローはステップ１１５０に進み、ローカル信頼キャッシュ１０３５が、信頼状態を有するプログラム・ファイルで更新される。

次に、フローはステップ１１５５に進み、全てのプログラム・ファイルが信頼できるかどうか（即ち、ネットワーク・アクセス試行と関連付けられたプログラム・ファイルが、中央サーバ２００への照会により非信頼状態を有すると判定されなかったか）の照会がされる。プログラム・ファイルが全て信頼できる場合は、フローはステップ１１７０に進んで、取り締まりが有効かどうか判定される。取り締まりが有効でない場合は、フローはステップ１１９０に進み、ソフトウェア・プロセス１０４５は、ネットワーク・アクセスを許可され、遮断パケットが、ＮＩＣ装置１０７０に渡される。しかしながら、ステップ１１７０で取り締まりが有効である場合は、ステップ１１７５でポリシーが評価されて、本明細書で前に述べたように、ポリシーが信頼状態を覆すかどうか判断される。ポリシーが、その１つ又は複数のプログラム・ファイルの信頼状態を覆す場合は、フローはステップ１１８０に進み、ソフトウェア・プロセス１０４５のネットワーク・アクセスが阻止される。しかしながら、ステップ１１７５で、その１つ又は複数のプログラム・ファイルの信頼状態が、ポリシーによって覆されない場合、フローはステップ１１９０に進み、ソフトウェア・プロセス１０４５は、ネットワーク・アクセスを許可され、発信パケットが、ＮＩＣ装置１０７０に渡される。

ステップ１１５５に再び関連して、プログラム・ファイルが全て信頼状態を有するとは限らない（即ち、中央サーバ２００への照会により、ネットワーク・アクセス試行と関連付けられた少なくとも１つのプログラム・ファイルが非信頼状態を有すると判定された）場合は、フローはステップ１１６０に進んで、ログ記録が有効かどうかが判断される。ログ記録が有効である場合は、フローはステップ１１６５に進み、図７に関連して本明細書で前に述べたように、ログ記録のためのイベント（即ち、ネットワーク・アクセス試行）を発生させる。次に、ログ記録のためのイベントが生成された後、又はステップ１１６０でログ記録が有効でない場合、フローはステップ１１７０に進み、取り締まりが有効かどうか判定される。取り締まりが有効でない場合、フローはステップ１１９０に進み、遮断パケットが、ＮＩＣ装置１０７０に渡され、ソフトウェア・プロセス１０４５は、ネットワークへのアクセスを許可される。しかしながら、ステップ１１７０で取り締まりが有効である場合は、図７に関連して本明細書で前に述べたように、ステップ１１７５でポリシーが評価されて、任意の構成ポリシーが、１つ又は複数のプログラム・ファイルの非信頼状態を覆し、ソフトウェア・プロセス１０４５によるネットワーク・アクセス又は選択的なネットワーク・アクセスが許可されるかどうかが判断される。

ポリシーが、ソフトウェア・プロセス１０４５に対応する１つ又は複数の非信頼プログラム・ファイルによる選択的なネットワーク・アクセスを許可するよう巧妙に作成されており、遮断パケットが、その特定のポリシー要件に適合する場合（例えば、パケットが、ポリシーによりアドレスの許可されたサブネットの範囲内にある宛先アドレスを含む、など）は、フローはステップ１１９０に進み、遮断パケットが、ＮＩＣ装置１０７０に渡され、ソフトウェア・プロセス１０４５は、ネットワークへのアクセスを許可される。しかしながら、プログラム・ファイルの非信頼状態が、ポリシーによって覆されない（即ち、ポリシーがアクセスを許可しないか、ポリシーが適用できない）場合は、フローはステップ１１８０に進み、遮断パケットがＮＩＣ装置１０７０に渡されず、ソフトウェア・プロセス１０４５は、ネットワーク・アクセスから阻止される。

また、図１１の保護フロー１１００は、ホスト１１００へのインバウンド・ネットワーク・アクセス試行の遮断、阻止及びログ記録アクティビティに使用されるフローを表わす。ステップ１１１０で、ローカル保護モジュール１０１０が、ＮＩＣ装置１０７０からのインバウンド・ネットワーク・アクセス試行を遮断する。インバウンド・ネットワーク・アクセス試行は、例えば、ＴＣＰリスン又はアクセプト・コールでよく、ソフトウェア・プロセス１０４５などの実行ソフトウェア・プロセスと関連付けられてもよい。着信遮断パケットは、ネットワーク・アクセス試行の発信遮断パケットに関連して本明細書で前に述べたステップ１１２０〜１１７５で評価される。ステップ１１２０〜１１７５のフローがステップ１１９０に進む場合、着信遮断パケットは、ホスト１０００へのアクセスを許可される。しかしながら、フローが、ステップ１１８０に進む場合は、着信遮断パケットは、ホスト１０００へのアクセスを阻止される。一例では、阻止は、リスン又はアクセプト・コールを失敗させ、リスン又はアクセプトＡＰＩの発呼者にエラーコードを返すことによって行われる。更に、本明細書で前に述べたように、インバウンド・ネットワーク・アクセス試行のための多数のポリシー構成が可能であり、インバウンド・ネットワーク・アクセス試行に適用されてもよい。例えば、ステップ１１７５で、ポリシーが、１つ又は複数の非信頼プログラム・ファイルと関連付けられた、選択されたインバウンド・ネットワーク・アクセス試行を許可するように巧妙に作成されており、着信パケットが、その特定のポリシー要件に適合する（例えば、パケットが、非信頼プログラム・ファイルに適用されるポリシーによりアドレスの許可されたサブネットの範囲内にあるソースアドレスを有するなど）と判断された場合、フローはステップ１１９０に進み、着信遮断パケットは、ホスト１０００へのアクセスを許可される。別の例では、ポリシーが、前のネットワーク・アクセス試行（即ち、インバウンド又はアウトバウンド）に適用され、また後のネットワーク・アクセス試行に適用される何らかのタイプの阻止に提供される場合は、後のインバウンド・ネットワーク・アクセス試行と関連付けられたプロセスが、対応するプログラム・ファイルが全て信頼状態を有する場合でも、そのポリシーによりホストへのアクセス又は選択的に許可されたアクセスが阻止されることがある。

図１２に移ると、図１２は、図１１のステップ１１４５に対応する信頼判定フロー１２００の詳細なフローを示し、ホスト１０００によって提供されるプログラム・ファイル（例えば、インバウンド又はアウトバウンド・ネットワーク・アクセス試行と関連付けられ、かつローカル信頼キャッシュ１０３５内に見つからなかったプログラム・ファイル）について、中央サーバ２００のソフトウェア信頼判定モジュール２４０によって行なわれることがある。フローは、ステップ１２１０で始まり、ホスト１０００が、ローカル信頼キャッシュ１０３５内に見つからなかったプログラム・ファイルの信頼判定を中央サーバ２００に照会する。ステップ１２１０で、中央サーバ２００は、ローカル信頼キャッシュ１０３５内で見つからなかった各プログラム・ファイルについて、ホワイトリスト・データ・フロー１０２４によりデータ（例えば、プログラム・ファイルのチェックサム）を受け取る。フローは、ステップ１２２０に進み、中央信頼キャッシュ２４５が、受け取ったプログラム・ファイル・チェックサムを探すために検索されることがある。中央信頼キャッシュ２４５は、内部又はグローバル・ホワイトリストへの照会を必要とせずに迅速に取り出すために、プログラム・ファイルの信頼性状態をキャッシュできるように使用されてもよい。ホスト１０００から受け取ったプログラム・ファイル・チェックサムが全て、ステップ１２２０の中央信頼キャッシュ２４５内に見つかった場合、フローはステップ１２５０に進み、各プログラム・ファイルの信頼状態が、ホスト１０００に返される。しかしながら、ステップ１２２０で、プログラム・ファイル・チェックサムが全て中央信頼キャッシュ２４５内で見つかったとは限らない場合、フローはステップ１２３０に進み、更なる評価が行なわれる。

ステップ１２３０で、図１に示されたグローバル・ホワイトリスト１６５などの１つ又は複数のグローバル・ホワイトリスト、及び／又は図１に示された内部ホワイトリスト１３３などの１つ又は複数の内部ホワイトリストを検索して、中央信頼キャッシュ２４５内に見つからなかった各プログラム・ファイルを探してもよい。一実施形態では、プログラム・ファイルを識別するためにホワイトリスト内でチェックサムが使用され、したがって、ステップ１２１０で中央サーバ２００に提供されたチェックサムが、ホワイトリストを検索するために使用される。プログラム・ファイル・チェックサムがホワイトリストに見つかった場合は、対応するプログラム・ファイルの信頼性状態が、信頼できると定義されるが、プログラム・ファイル・チェックサムがどのホワイトリストにも見つからなかった場合は、対応するプログラム・ファイルの信頼性状態が、信頼できないと定義される。ホワイトリストが検索された後、フローはステップ１２４０に進み、中央信頼キャッシュ２４５が、信頼状態を有する（即ち、内部及び／又は外部ホワイトリストのうちの１つに見つかった）プログラム・ファイルで更新される。中央信頼キャッシュ２４５が更新された後で、フローはステップ１２５０に進み、各プログラム・ファイルの信頼性状態（即ち、信頼できないか信頼できるか）をホスト１０００に返す。

図１０〜図１２に述べた実施形態は、悪意のあるソフトウェアからローカル保護するシステムを強化するように多くの方法で改良されてもよいことは明白であろう。例えば、ホスト１０００又は中央サーバ２００のモジュールには、図５と図６に関連して本明細書で前に述べたように、非信頼状態を有すると判定されたソフトウェア・プログラム・ファイルのヒューリスティックな条件（例えば、プログラム・ファイルの所有者、修正日、作成日、プログラム・ファイル属性など）の評価を提供するロジックが含まれてもよい。１つ又は複数の既定条件が存在する場合は、プログラム・ファイルが、信頼状態に昇格されてもよい。しかしながら、プログラム・ファイルに適用される既定条件がない場合は、非信頼状態が持続し、プログラム・ファイルは、信頼できないと定義されてもよい。本明細書で前に述べたように、ホワイトリストに加えて、ブラックリストを評価する追加のロジックを含んでもよい。

また、代替のホスト構成を使用してシステムの様々な実施形態が実現されることが理解されよう。例えば、ＮＤＩＳドライバ・スタックとＡＰＩフック構成とを有するホストを含むネットワーク内に実現された非信頼ソフトウェア・インベントリを有する実施形態が示され説明された。非信頼ソフトウェア・インベントリのないシステムの実施形態が、ＮＤＩＳドライバ・スタック・ホスト構成を有するネットワーク内に実現されるように示され説明された。しかしながら、ＮＤＩＳドライバ・スタック、ＡＰＩフッキング、又は様々な他のホスト構成（例えば、トランスポート・ドライバ・インタフェース（ＴＤＩ）、Ｕｎｉｘ（登録商標） Ｓｔｒｅａｍｓ、カーネル空間ネットワーク・スタック・フッキングなど）を有するネットワーク内に、実施形態のいずれかが実現されてもよい。例えば、ＴＤＩインプリメンテーションでは、ローカル保護構成要素は、図３と図１０に示されたものに類似の方式で実施され機能してもよい。しかしながら、ＴＤＩインプリメンテーションでは、ローカル保護モジュールが、ＴＣＰ／ＩＰプロトコルの下ではなく上にあってもよい。

悪意のあるソフトウェアからローカル保護するためのシステム及び方法の１つの代替の実施形態において、システムは、帯域外のプログラム・ファイルを列挙し、それらの列挙されたプログラム・ファイルの信頼性状態を判定し、カリフォルニア州サンタクララのＩｎｔｅｌ社によって製造されたＩｎｔｅｌ（登録商標）Ａｃｔｉｖｅ Ｍａｎａｇｅｍｅｎｔ Ｔｅｃｈｎｏｌｏｇｙ（ＡＭＴ）を使用して非信頼プログラム・ファイルによるネットワーク・アクセスを阻止するように構成されてもよい。この例示的実施形態では、ＡＭＴは、ホスト１２０ａ、１２０ｂ又は１２０ｃなどのホストのプログラム・ファイルの帯域外検査を実行し、ソフトウェア・インベントリを作成するために使用されてもよい。この列挙が行われた後で、ソフトウェア・インベントリ内のプログラム・ファイルが評価されて本明細書で述べたような信頼性状態が判定されてもよく、ローカル及び／又は中央非信頼ソフトウェア・インベントリが作成され更新されてもよい。ＡＭＴを使用することにより、非信頼プログラム・ファイルと関連したファイアウォール規則が、それぞれのホストのハードウェア内に構成されてもよい。具体的には、ホストのＮＩＣ装置上に配置されたフィルタが、非信頼プログラム・ファイルを阻止するように構成されてもよい。この構成は、指定された時間（例えば、所定の時間間隔、非信頼ソフトウェア・インベントリが更新されたとき、オンデマンドなど）で行なわれてもよい。

代替のＡＭＴ実施形態では、ＮＩＣ装置上のフィルタの構成が、実時間で行なわれてもよい。ネットワーク・アクセス試行が行われるたびに、例えば、図１０〜図１２の実施形態に関連して本明細書で示し述べたように、遮断、関連プログラム・ファイルの判定、及びプログラム・ファイルの信頼判定が行なわてもよい。その場合、オペレーティング・システムは、関連プログラム・ファイルのどれかが信頼できないと判定された場合に、ＡＭＴファイアウォール規則を更新してもよい。ＡＭＴを使用する更に別の実施形態では、実行可能ソフトウェアの列挙が、帯域外で行われてもよく、１つ又は複数の非信頼ソフトウェア・インベントリが、作成され維持されてもよく、阻止が、本明細書に示し述べた他の実施形態（例えば、ＮＤＩＳドライバ・スタック、ＡＰＩフッキングなど）によって行われてもよい。

別の実施形態では、図１のローカル保護構成要素１２４ａ、１２４ｂ及び１２４ｃなどのローカル保護構成要素内で、アプリケーション・レベルのフィルタリングが使用されてもよい。アプリケーション・レベルのフィルタリングでは、Ｗｉｎｄｏｗｓ（登録商標） Ｆｉｒｅｗａｌｌ（カリフォルニア州レドモンドのＭｉｃｒｏｓｏｆｔ社により製造された）などの特定の許可及び／又は阻止アプリケーションに対応するように適応されたファイアウォールが、ローカル又は中央非信頼ソフトウェア・インベントリと共に使用されてもよい。例えば、ローカル非信頼ソフトウェア・インベントリが、本明細書に記載されたように作成されてもよい。非信頼ソフトウェア・インベントリが読み込まれた後で、インベントリが更新されたとき、ブロック規則（例えば、特定のアプリケーションの阻止、プログラム・ファイルと関連付けられたポートの阻止など）が、非信頼ソフトウェア・インベントリで識別されたソフトウェア・プログラム・ファイルのために作成され、次にファイアウォール内で非信頼ソフトウェア・プログラム・ファイルと関連付けられたネットワーク・アクセス試行を阻止するように更新されてもよい。したがって、ネットワーク・アクセス試行が、１つ又は複数の非信頼プログラム・ファイルにマッピングされた実行ソフトウェア・プロセスと関連付けられたときは、ファイアウォールは、ネットワーク・アクセス試行を阻止する。

更に別の実施形態では、コンピュータ・ネットワークを保護するシステム及び方法が、仮想環境で実現されてもよい。この例示的実施形態では、仮想機械に対応するハードディスク・ファイルの帯域外検査を行なうことができる。ホスト１２０ａ、１２０ｂ又は１２０ｃなどのホストのディスク・ファイルは、仮想機械が動作しているハイパーバイザーから開かれてもよく、その結果、全ての実行可能ソフトウェアを見て列挙することができる。列挙されたソフトウェア・プログラム・ファイルを評価して本明細書に記載された信頼性状態を判定することができ、また非信頼ソフトウェア・インベントリを作成し維持することができる。また、ハイパーバイザーを使用してネットワーク・アクセス試行をフィルタリングして、非信頼ソフトウェア・プログラム・ファイルと関連付けられたインバウンド及びアウトバウンド・ネットワーク・アクセス試行を阻止することができる。この実施形態は、データセンター又は仮想デスクトップ・インタフェース（ＶＤＩ）環境で実施されてもよい。代替の実施形態では、仮想機械ディスク・ファイルの帯域外検査を使用して非信頼ソフトウェア・インベントリが作成された後で、本明細書で述べた他の技術（例えば、ＮＤＩＳスタック、ＡＰＩフッキングなど）を使用して取り締まりが実行されてもよい。

本明細書で概説された操作を達成するソフトウェアは、様々な場所（例えば、企業ＩＴ本部、エンドユーザ・コンピュータ、クラウド内の分散サーバなど）に提供することができる。他の実施形態では、このソフトウェアは、悪意のあるソフトウェアに対するローカル保護をするこのシステムを提供するために、（例えば、別個のネットワーク、装置、サーバなどの個別のエンドユーザ・ライセンスを購入する状況で）ウェブサーバから受け取られ、又はダウンロードされてもよい。１つの例示的実施態様では、このソフトウェアは、セキュリティ攻撃から保護しようとする（又は、データの望ましくないか又は無許可の操作から保護された）１つ又は複数のコンピュータ内に常駐する。

他の例では、悪意のあるソフトウェアに対するローカル保護をするシステムのソフトウェアは、知的所有権下にある要素（例えば、ＭｃＡｆｅｅ（登録商標）Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｒｏｌソフトウェア、ＭｃＡｆｅｅ（登録商標）Ｃｈａｎｇｅ Ｃｏｎｔｒｏｌソフトウェア、ＭｃＡｆｅｅ（登録商標）ｅＰｏｌｉｃｙ Ｏｒｃｈｅｓｔｒａｔｏｒソフトウェア、ＭｃＡｆｅｅ（登録商標）Ｐｏｌｉｃｙ Ａｕｄｉｔｏｒソフトウェア、ＭｃＡｆｅｅ（登録商標）Ａｒｔｅｍｉｓ Ｔｅｃｈｎｏｌｏｇｙソフトウェア、ＭｃＡｆｅｅ（登録商標）Ｈｏｓｔ Ｉｎｔｒｕｓｉｏｎ Ｐｒｅｖｅｎｔｉｏｎソフトウェア、ＭｃＡｆｅｅ（登録商標）ＶｉｒｕｓＳｃａｎソフトウェアなどによるネットワーク・セキュリティ・ソリューションの一部として）を含むことがあり、これらの識別された要素内（又はその近く）に提供されてもよく、任意の他の装置、サーバ、ネットワーク機器、コンソール、ファイアウォール、スイッチ、ルータ、情報技術（ＩＴ）装置、分散サーバなどの中に提供されてもよく、相補的ソリューション（例えば、ファイアウォールと関連）として提供されてもよく、ネットワーク内のどこかに提供されてもよい。

図１に示したような例示的なローカル・ネットワーク１１０において、ホスト１２０及び中央サーバ１３０は、悪意のあるソフトウェアからコンピュータ・ネットワークを保護することを容易にするコンピュータ又は計算装置である。本明細書で使用されるとき、用語「コンピュータ」及び「計算装置」は、パーソナルコンピュータ、ネットワーク機器、ルータ、スイッチ、ゲートウェイ、プロセッサ、サーバ、ロードバランサ、ファイアウォール、又はネットワーク環境で電子情報に影響を及ぼすか又は処理するように動作可能な他の適切な装置、構成要素、要素又は物体を包含することを意図する。更に、このコンピュータ及び計算装置は、その動作を容易にする任意の適切なハードウェア、ソフトウェア、構成要素、モジュール、インタフェース、又は物体を含んでもよい。これは、データの有効な保護及び通信を可能にする適切なアルゴリズム及び通信プロトコルを含んでもよい。

特定の例示的な実施態様では、本明細書で概説した悪意のあるソフトウェアに対するコンピュータ・ネットワークの保護に関係するアクティビティは、ソフトウェアで実現されてもよい。これは、中央サーバ１３０（例えば、中央保護構成要素１３５）とホスト１２０（例えば、ローカル保護構成要素１２４）内に提供されたソフトウェアを含むことができる。これらの構成要素、要素及び／又はモジュールは、互いに協力して、本明細書で述べたように、ボットネットなどの悪意のあるソフトウェアに対するローカル保護を提供するアクティビティを実行することができる。他の実施形態では、これらの特徴は、これらの要素の外部に提供されもよく、これらの意図された機能を達成する他の装置に含まれてもよく、任意の適切な方法で統合されてもよい。例えば、保護アクティビティは、更にホスト１２０内に局在化されるか中央サーバ１３０内に更に集中されてもよく、図示されたプロセッサの幾つかは、除去され、その他特定のシステム構成に適応するように統合されてもよい。一般的な意味において、図１に示された機構は、その説明がより論理的であってもよいが、物理的アーキテクチャは、これらの構成要素、要素及びモジュールの様々な順列／組み合わせ／混合物を含んでもよい。

これらの要素（ホスト１２０及び中央サーバ１３０）は全て、本明細書に概説されたような信頼判定、ログ記録及び取り締まりを含む保護アクティビティを達成するために連係し、管理し、その他協力することができるソフトウェア（又は、レシプロケーティング・ソフトウェア）を含む。更に他の実施形態では、これらの要素の１つ又は全ては、その動作を容易にする任意の適切なアルゴリズム、ハードウェア、ソフトウェア、構成要素、モジュール、インタフェース、又はオブジェクトを含んでもよい。ソフトウェアを含む実施態様において、そのような構成は、１つ又は複数の有形媒体内に符号化されたロジック（例えば、特定用途向け集積回路（ＡＳＩＣ）内に提供された埋込みロジック、デジタル・シグナル・プロセッサ（ＤＳＰ）命令、プロセッサや他の類似の装置によって実行されるソフトウェア（オブジェクト・コード及びソースコードを含む可能性がある）など）を含んでもよく、有形媒体は持続的媒体を含む。これらの例の幾つかでは、１つ又は複数のメモリ要素（図１、図２、図３、図８及び図１０を含む様々な図に示されたような）は、本明細書に詳述された操作に使用されるデータを記憶することができる。これは、本明細書に記載されたアクティビティを行うために実行されるソフトウェア、ロジック、コード又はプロセッサ命令を記憶することができるメモリ要素を含む。プロセッサは、本明細書に記載された操作を達成するデータと関連付けられた任意のタイプの命令を実行することができる。一例では、プロセッサ（図２、図３、図８及び図１０に示されたような）は、要素又は物品（例えば、データ）をある状態又は物事から別の状態又は物事に変換することができる。別の例では、本明細書で概説されたアクティビティは、固定ロジック又はプログラマブル・ロジック（例えば、プロセッサによって実行されるソフトウェア／コンピュータ命令）で実現されてもよく、本明細書に識別された要素は、デジタル・ロジック、ソフトウェア、コード、電子命令、又はこれらの任意の適切な組み合わせを含む何らかのタイプのプログラマブル・プロセッサ、プログラマブル・デジタル・ロジック（例えば、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、消去可能なプログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、又はＡＳＩＣで実現されてもよい。

これらの要素（例えば、コンピュータ、ホスト、サーバ、分散サーバなど）はどれも、本明細書に概説されたような保護アクティビティの達成に使用される情報を記憶するためのメモリ要素を含むことができる。更に、これらの装置はそれぞれ、本明細書で述べたような保護アクティビティを行うソフトウェア又はアルゴリズムを実行することができるプロセッサを含んでもよい。これらの装置は、更に、情報を、必要に応じかつ特定の要求に基づいて、任意の適切なメモリ要素（例えば、ランダムアクセスメモリ（ＲＡＭ）、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＡＳＩＣなど）、ソフトウェア、ハードウェア、あるいは他の適切な構成要素、装置、要素又はオブジェクト内に維持してもよい。本明細書で述べたメモリ項目（例えば、ログ・イベント・データベース、中央非信頼ソフトウェア・インベントリ、ローカル非信頼ソフトウェア・インベントリ、内部ホワイトリスト、ポリシー・データベース、プロセス・トラフィック・マッピングデータベース、チェックサム・キャッシュ、ローカル信頼キャッシュ、中央信頼キャッシュなど）はいずれも、幅広い用語「メモリ要素」に包含されるように解釈されるべきである。同様に、本明細書に述べた潜在的な処理要素、モジュール及び機械はいずれも、幅広い用語「プロセッサ」に包含されるように解釈されるべきである。また、コンピュータ、ホスト、サーバ、分散サーバなどはそれぞれ、ネットワーク環境でデータ又は情報を受信し、送信し、その他通信するのに適切なインタフェースを含んでもよい。

本明細書に提供された例では、２つ、３つ、４つ、又はこれより多くのネットワーク構成要素に関する相互作用が記述されていることに注意されたい。しかしながら、これは、明瞭さと単なる例のために行われた。悪意のあるソフトウェアに対するローカル保護をするシステムは、任意の適切な方法で統合できることを理解されたい。類似の設計選択に沿って、図の示されたコンピュータ、モジュール、構成要素及び要素はいずれも、様々な可能な構成で組み合わされてもよく、これらは全て、本明細書の広い範囲内にあることは明らかである。特定の事例では、限られた数の構成要素又はネットワーク要素だけを参照して所定の組のフローの機能の１つ又は複数について記述する方が容易なことがある。したがって、図１（及びその教示）のシステムが、容易に拡張可能であることを理解されたい。システムは、多数の構成要素、並びにより複雑又は高度な機構及び構成に適応することができる。したがって、提供された例は、範囲を制限せず、また様々な他のアーキテクチャに潜在的に適用されるようなローカル保護をするシステムの幅広い教示を妨げるべきではない。

また、以上の図に関連して述べた操作が、悪意のあるソフトウェアに対するローカル保護をするシステムによって又はそのシステム内で実行される可能性のあるシナリオの一部だけを示すことに注意することが重要である。これらの操作の幾つかは、必要に応じて削除又は除去されてもよく、あるいはこれらの操作は、述べた概念の範囲を逸脱せずに大幅に修正又は変更されてもよい。更に、これらの操作と様々なステップのタイミングは、この開示に教示された結果を達成するように大幅に変更されてもよい。例えば、信頼判定処理は、グローバル又は外部ホワイトリストより前に内部ホワイトリストを評価してもよい。したがって、以上の動作フローは、例示と検討のために提示された。システムは、述べた概念の教示から逸脱することなく任意の適切な機構、時系列、構成及びタイミングが提供されるという点で、実質的な柔軟性を提供する。

Claims (22)

1. 計算装置のプロセッサによって実行されるコンピュータプログラムであって、前記プロセッサが前記コンピュータプログラムを実行することにより、
   前記計算装置上で実行しているプロセスと関連付けられたネットワークアクセス試行を、前記計算装置上で遮断し、
   前記プロセスにマッピングされた複数のソフトウェアプログラムファイルを判定し、
   前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあるかを判定し、
   前記ソフトウェアプログラムファイルのなかに信頼されないものがあると判定した場合、前記ネットワークアクセス試行と関連付けられたネットワークアドレスが許可ネットワークアドレスの組のなかに含まれているか判定し、
   前記ネットワークアドレスが前記許可ネットワークアドレスの組のなかに含まれていると判定した場合、前記ネットワークアクセス試行を許可する、
   コンピュータプログラム。
2. 前記ネットワークアクセス試行は、前記計算装置から宛先ノードへ向かう外向きであり、
   前記ネットワークアドレスは、前記宛先ノードと関連付けられている、
   請求項１のコンピュータプログラム。
3. 前記ネットワークアクセス試行は、ソースノードから前記計算装置へ向かう内向きであり、
   前記ネットワークアドレスは、前記ソースノードと関連づけられている、
   請求項１のコンピュータプログラム。
4. 前記複数のソフトウェアプログラムファイルのうち少なくとも一つのソフトウェアプログラムファイルは、実行可能ファイルであり、
   前記複数のソフトウェアプログラムファイルのうち別の少なくとも一つのソフトウェアプログラムファイルは、前記プロセスにロードされたライブラリモジュールである、
   請求項１乃至３いずれかのコンピュータプログラム。
5. 前記プロセッサは、更に、
   前記ソフトウェアプログラムファイルのなかに信頼されないものがあると判定し、なおかつ、前記ネットワークアクセス試行と関連付けられた前記ネットワークアドレスが前記許可ネットワークアドレスの組に含まれないと判定した場合に、前記ネットワークアクセス試行を阻止する、
   請求項１乃至４いずれかのコンピュータプログラム。
6. 前記プロセッサは、更に、
   前記ソフトウェアプログラムファイルがすべて信頼されると判定した場合、前記ネットワークアクセス試行を許可する、
   請求項１乃至５いずれかのコンピュータプログラム。
7. 前記プロセッサは、
   ネットワークアクセスポリシーが、前記ソフトウェアプログラムファイルのなかに信頼されないものがあると判定した場合に前記ネットワークアクセス試行を許可しない場合であっても、前記ネットワークアクセス試行と関連づけられた前記ネットワークアドレスが、前記許可ネットワークアドレスの組に含まれる場合は、前記ネットワークアクセス試行を許可する、
   請求項１乃至６いずれかのコンピュータプログラム。
8. 前記プロセッサは、
   前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあるかの判定において、ソフトウェアプログラムファイルがホワイトリストのなかで識別されない場合に、前記ソフトウェアプログラムファイルが信頼されないと判定する、
   請求項１乃至７いずれかのコンピュータプログラム。
9. 前記プロセッサは、
   前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあるかの判定において、
   信頼ソフトウェアプログラムファイルを識別するローカルキャッシュを検索して、ソフトウェアプログラムファイルが識別されるか判定し、
   前記ソフトウェアプログラムファイルがローカルキャッシュによって識別されない場合、前記ソフトウェアプログラムファイルの信頼性状態を、中央サーバに照会し、
   前記信頼性状態が、前記ソフトウェアプログラムファイルが信頼されることを示す場合に、前記ソフトウェアプログラムファイルを識別するよう、前記ローカルキャッシュを更新する、
   請求項１乃至８いずれかのコンピュータプログラム。
10. 前記プロセッサは、
    前記ネットワークアクセス試行の遮断において、前記プロセスのなかにロードされたネットワークフックを使用して、前記ネットワークアクセス試行と関連付けられたアプリケーションプログラムインタフェースを遮断する
    請求項１乃至９いずれかのコンピュータプログラム。
11. 前記プロセッサは、
    前記プロセスにマッピングされた複数のソフトウェアプログラムファイルの判定において、オペレーティングシステムのアプリケーションプログラムインタフェースを使用する、
    請求項１乃至１０いずれかのコンピュータプログラム。
12. 前記プロセッサは、更に、
    前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあると判定した場合に、前記ネットワークアクセス試行に関係する情報をログ記録する
    請求項１乃至１１いずれかのコンピュータプログラム。
13. 保護モジュールと、前記保護モジュールに関連付けられた命令を実行可能なプロセッサとを備え、前記プロセッサが前記命令を実行することにより、
    計算装置上で実行しているプロセスと関連付けられたネットワークアクセス試行を、前記計算装置上で遮断し、
    前記プロセスにマッピングされた複数のソフトウェアプログラムファイルを判定し、
    前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあるかを判定し、
    前記ソフトウェアプログラムファイルのなかに信頼されないものがあると判定した場合、前記ネットワークアクセス試行と関連付けられたネットワークアドレスが許可ネットワークアドレスの組のなかに含まれているか判定し、
    前記ネットワークアドレスが前記許可ネットワークアドレスの組のなかに含まれていると判定した場合、前記ネットワークアクセス試行を許可する、
    装置。
14. 前記複数のソフトウェアプログラムファイルのうち少なくとも一つのソフトウェアプログラムファイルは、実行可能ファイルであり、
    前記複数のソフトウェアプログラムファイルのうち別の少なくとも一つのソフトウェアプログラムファイルは、前記プロセスにロードされたライブラリモジュールである、
    請求項１３の装置。
15. 前記プロセッサは、更に、
    前記ソフトウェアプログラムファイルのなかに信頼されないものがあると判定し、なおかつ、前記ネットワークアクセス試行と関連付けられた前記ネットワークアドレスが前記許可ネットワークアドレスの組に含まれないと判定した場合に、前記ネットワークアクセス試行を阻止する、
    請求項１３又は１４の装置。
16. 前記プロセッサは、
    ネットワークアクセスポリシーが、前記ソフトウェアプログラムファイルのなかに信頼されないものがあると判定した場合に前記ネットワークアクセス試行を許可しない場合であっても、前記ネットワークアクセス試行と関連づけられた前記ネットワークアドレスが、前記許可ネットワークアドレスの組に含まれる場合は、前記ネットワークアクセス試行を許可する、
    請求項１３乃至１５いずれかの装置。
17. 前記プロセッサは、
    前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあるかの判定において、ソフトウェアプログラムファイルがホワイトリストのなかで識別されない場合に、前記ソフトウェアプログラムファイルが信頼されないと判定する、
    請求項１３乃至１６いずれかの装置。
18. 前記プロセッサは、
    前記プロセスにマッピングされた複数のソフトウェアプログラムファイルの判定において、オペレーティングシステムのアプリケーションプログラムインタフェースを使用する、
    請求項１３乃至１７いずれかの装置。
19. 計算装置上で実行しているプロセスと関連付けられたネットワークアクセス試行を、前記計算装置上で遮断し、
    前記プロセスにマッピングされた複数のソフトウェアプログラムファイルを判定し、
    前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあるかを判定し、
    前記ソフトウェアプログラムファイルのなかに信頼されないものがあると判定した場合、前記ネットワークアクセス試行と関連付けられたネットワークアドレスが許可ネットワークアドレスの組のなかに含まれているか判定し、
    前記ネットワークアドレスが前記許可ネットワークアドレスの組のなかに含まれていると判定した場合、前記ネットワークアクセス試行を許可する、
    方法。
20. 前記ネットワークアクセス試行は、前記計算装置から宛先ノードへ向かう外向きであり、
    前記ネットワークアドレスは、前記宛先ノードと関連付けられている、
    請求項１９の方法。
21. 前記複数のソフトウェアプログラムファイルのなかに信頼されないものがあるかの判定において、ソフトウェアプログラムファイルがホワイトリストのなかで識別されない場合に、前記ソフトウェアプログラムファイルが信頼されないと判定する、
    請求項１９又は２０の方法。
22. 前記複数のソフトウェアプログラムファイルのうち少なくとも一つのソフトウェアプログラムファイルは、実行可能ファイルであり、
    前記複数のソフトウェアプログラムファイルのうち別の少なくとも一つのソフトウェアプログラムファイルは、前記プロセスにロードされたライブラリモジュールである、
    請求項１９乃至２１いずれかの方法。

Images