JP4864333B2 - ソフトウェアの脆弱性の悪用を防止するように通信をフィルタ処理するための方法およびシステム - Google Patents

Description

本発明の技術は、全般的に、アプリケーションの脆弱性の悪用を検出しかつ防止することに関する。

インターネットはコンピュータシステム間の通信を容易にすることや電子商取引を可能にすることに関して大きな成功を収めているが、インターネットに接続されているコンピュータシステムは、その動作を妨害しようと狙っているハッカーによる攻撃に対してほとんど常時曝された状態に置かれている。こうした攻撃の多くは、これらのコンピュータシステム上で動作するアプリケーションプログラムその他のコンピュータプログラムの脆弱性を悪用しようと狙っている。コンピュータシステムを攻撃する最も破壊的な方法のうちの１つはコンピュータプログラムに「ワーム（ｗｏｒｍ）」を送り込むことである。ワームは、脆弱性を悪用する自己増殖型の攻撃の１つであり、その攻撃は、コンピュータシステムの支配権を握りこのコンピュータシステムを使って同じ脆弱性をもつ別のコンピュータシステムに対する攻撃を仕掛ける（すなわち、同じワームを送りつける）ことによる。ワームは、受信しているコンピュータプログラムの脆弱性を悪用するように設計された１つのメッセージまたは一連のメッセージである。この１つのメッセージまたは複数のメッセージを受信すると、そのコンピュータプログラムは、そのコンピュータシステムに対するワームによる支配権の取得を可能にさせるいくつかの措置を実施する。

アプリケーションの開発者およびコンピュータシステムの管理者は、脆弱性を識別して除去するために多大に労力および経費を費やしている。しかし、アプリケーションの複雑さのために、アプリケーションをリリースする前に脆弱性をすべて識別し除去することは事実上不可能である。アプリケーションがリリースされた後で、開発者は様々なやり方で脆弱性を認識する可能性がある。悪意のない第三者がアプリケーションの脆弱性を発見することがあり、またこうした第三者が開発者に内密にこれを知らせ、ハッカーがこれを見付けて悪用する前に脆弱性を除去できることがある。ハッカーが最初に脆弱性を発見した場合は、開発者はその脆弱性についてはこれが悪用される（悲惨な結果を伴うこともある）まで熟知していないことがある。

開発者が脆弱性についてどの様にして見出したのかに関わりなく、開発者はその脆弱性を除去する「パッチ（ｐａｔｃｈ）」を開発してシステム管理者に配布するのが一般的である。その脆弱性がまだ悪用されていない場合（例えば、ハッカーに知られていないことがある）、開発者はきちんとした方法でパッチを設計、実現、試験、および配布することができる。その脆弱性がすでに広く露呈されている場合、開発者はパッチを急いで配布することがあり、通常の状況下で用いられるのと同じ慎重さを伴わないことがある。コンピュータシステムの管理者にパッチが配布されると、彼らは脆弱性を除去するためにそのパッチに関するスケジューリングおよびインストールを行う責任がある。

しかしながら、様々な理由で管理者は脆弱性を除去するためのパッチのインストールを遅延させることが多い。パッチがインストールされると、アプリケーション、ならびにアプリケーションをその上で動作させているコンピュータシステムは、シャットダウンして再起動させることが必要となることがある。その脆弱性がある組織の成果にとって極めて重要なアプリケーション内に存在する場合、管理者はアプリケーションを立ち上げた稼働状態に保ってこれに関連した攻撃を受けるリスクを取るか、パッチのインストールのために極めて重要なリソースをシャットダウンするかに関してその兼ね合いを解析する必要がある。ある管理者らは、性急な配布であるため適正に試験がなされておらず意図しない副作用を有している可能性があることを懸念して、パッチのインストールを遅延させることがある。パッチが意図しない副作用を有していると、そのパッチそれ自体によってアプリケーション（または、コンピュータシステム）がシャットダウンされることがある。管理者は、パッチをインストールするか否かを判断する際には、意図しない副作用の可能性を織り込んでおく必要がある。これらの管理者は、他の管理者による経験によって意図しない重大な副作用が存在しないことが示されるまでパッチのインストールを遅延させることがある。

アプリケーション内の脆弱性の悪用を防止するためには別の方法も利用可能である。例えば、悪用のソースが既知であれば、そのソースからのすべてのメッセージについてこれらがアプリケーションに到達する前に阻止して廃棄することができる。しかし、攻撃ソースは厳密には識別できないことがあり、こうなると多くの善良なソースからのメッセージも廃棄されることがある。別の例として、脆弱性を悪用しようと試みるメッセージは、これがアプリケーションまで送られる前に検出し廃棄できるようなある種の特徴（例えば、非常に長いファイル名）を有していることがある。

脆弱性の悪用を防止するための現行の方法は、様々な理由で、完全に満足のゆくものではない。ある管理者らは単に脆弱性の悪用を防止できるほどに迅速にパッチをインストールしないことがあるという理由のため、パッチのインストールは完全に満足のゆくものではない。さらに、パッチはそれ自体が、脆弱性の悪用と比べてより大きな損害をもたらす副作用を有している可能性もある。悪用の試みを識別するためのメッセージの阻止もまた、その識別が知られている悪用に基づいているため完全に満足のゆくものではなく、さらに同じ脆弱性に関する未知の悪用を防止できないことがある。パッチを必要とせず、また脆弱性の具体的な任意の悪用と独立した方式で脆弱性の悪用を防止することができることが望ましい。

あるコンポーネントの通信プロトコルの状態が満足された時点を識別するための方法およびシステムを提供する。一実施形態では、本システムは、通信プロトコルの少なくとも一部分（すなわち、通信プロトコルのモデル）を指定する指定基準（specification）を提供すると共に、何時条件が満足されるのかを通信プロトコルの指定された部分内に示している。そのコンポーネントに対する通信が受信されると、コンポーネントによって通信が処理される前に、本システムは受信した通信が条件を満足するか否かを、提供された指定基準の指定に従って判定する。次いで、本システムは条件が満足されたか否かに応じた適当な措置を取ることができる。例えば、その条件がコンポーネントの脆弱性を曝露させることに関連する場合、本システムは、脆弱性の曝露を防止するために、条件が満足されたときにはそのコンポーネントに対して通信を提供しないという措置を取ることがある。

通信プロトコル（例えば、メッセージベースまたはストリームベースのプロトコル）を実装しているアプリケーションなどのコンポーネントを、通信ベースの脆弱性の悪用に対して保護するための方法およびシステムを提供する。一実施形態では、防護システムによって、ある識別の脆弱性を曝露させるメッセージを認識する方法を指定しかつ脆弱性が曝露されたときに取るべき措置を指定している「防護ポリシー」が提供される。防護ポリシーは、脆弱性を曝露させる一連のメッセージおよびそのペイロードの特徴を指定している。この防護システムは、メッセージプロトコルステートマシンを用いてメッセージのシーケンスを指定することがある。アプリケーションのメッセージプロトコルステートマシンは、アプリケーションが様々なメッセージを受信するに従って遷移して行く状態のことを意味している。ある防護ポリシーのメッセージプロトコルステートマシンは、アプリケーションのメッセージプロトコルステートマシンのうちの脆弱性に関連した一部分とすることがある。この防護システムは、メッセージプロトコルステートマシンを使用して結果的に脆弱性の曝露につながる状態をトラッキングしている。この防護ポリシーは実施されるべき措置を、現行の状態ならびに受信したまたは現行のメッセージに従って指定することがある。これらの措置は、ある条件が満たされたか否かを判定するためのメッセージのペイロードに対するチェック、メッセージプロトコルステートマシンに関する次の状態の識別、メッセージの廃棄、メッセージのソースとの切断、その他を含むことがある。この防護ポリシーは脆弱性に関連付けされたメッセージプロトコルに基づいているため、この防護ポリシーは脆弱性の任意の悪用から独立している。したがって、この防護システムは、そのアプリケーションによって使用される通信ベースのプロトコルをモデル化し、脆弱性の曝露などの条件を検出しかつ防止することができる。

一実施形態では、防護ポリシーには、アプリケーションの脆弱性、ならびにその脆弱性の悪用に対する防護のための措置が記述されている。防護ポリシーには２つの部分がある。その第１の部分は、プロトコル状態、イベント、および使用したポートなどのアプリケーションレベルの一般プロトコル情報、イベントタイプの位置、セッション識別子、およびパケット内のシーケンス番号、およびメッセージ境界マーカ（message boundary markers）を規定している。その第２の部分は、ハンドラー（すなわち、措置の組）およびメッセージペイロード構文解析命令を規定している。このハンドラーは、メッセージペイロードを検査し脆弱性の任意の悪用を識別するため、ならびにその悪用を防止するように対抗策を取るか後で悪用の識別するために必要なセッション情報を記録するために、実行時に起動される。この防護システムは、実行時間の前に、ハンドラーおよび防護ポリシーのペイロード命令を構文解析し、かつ実行時により効率よく処理できるようにするためこれらをシンタックスツリー内に保存する。この防護システムは、防護ポリシーの第１の部分とシンタックスツリーとを「脆弱性指定基準（vulnerability specification）」として保存する。この脆弱性指定基準は、状態、イベント、およびハンドラーからなるトリプレット（triplet）を含むことがある。

メッセージがアプリケーションに送られてしまう前に防護システムがそのメッセージを受信すると、防護システムはそのメッセージに対応するイベント、ならびにそのアプリケーションのメッセージプロトコルステートマシンの現行の状態を識別する。次いで、防護システムは、そのトリプレットによる指示に従って現行の状態および現行のイベントに関連付けされたハンドラーを識別して実行する。このハンドラーは、脆弱性の曝露につながる特徴が存在しているか否かを判定するためにメッセージ（そのペイロードを含む）を解析することがある、このメッセージの特徴に応じて現行の状態を次の状態に変更することがある、別のメッセージを受信したときに後続の判定を実施するのに必要な状態情報を保存することがある、識別された悪用に対する対抗措置を実施することがある、等々である。防護システムによってあるメッセージが脆弱性を曝露させることになると判定された場合、このメッセージはアプリケーションに提供しない。したがって、この防護システムによれば、アプリケーションにパッチをかけることなく、アプリケーションの脆弱性の悪用が防止される。さらに、この防護システムは、メッセージベースの異なる多くのアプリケーションに関して脆弱性の悪用を防止するために使用することが可能な一般的なフレームワークである。

一実施形態では、その防護システムは、ネットワークプロトコルのトランスポートレイヤとアプリケーションレイヤの間で動作する。しかし当業者であれば、防護システムが、様々なネットワークプロトコルレイヤの間でまたは様々なネットワークプロトコルレイヤの内部で、また複数のプロトコルレイヤで同時に実行することができることを理解されよう。例えば、いくつかのアプリケーションは、アプリケーションがメッセージの処理を実施する前にメッセージを前処理するためにフック（ｈｏｏｋ）を提供することがある。こうしたアプリケーションについて、この防護システムはアプリケーションレイヤで動作して、そのメッセージがアプリケーションによって処理される前にメッセージを処理することができる。その防護システムによってある脆弱性が曝露されると判定された場合、防護システムはそのメッセージを廃棄すること、アプリケーションを中止させること、あるいは何らかの適当な別の措置を取ることができる。

複数のクライアントに対してサービス提供しているアプリケーションは、どのクライアントがメッセージを送ったのかを識別する際に使用するために、各クライアントに対して１つのセッション識別子を割り当てることがある。単一のクライアントが複数のセッションを有する、したがって複数のセッション識別子を有することがある。このケースでは、１つのセッション識別子が、あるクライアントの具体的な１つのセッションを識別している。あるセッション内の一連のメッセージによって脆弱性が曝露されることがあり得る。したがって、この防護システムは各セッションごとにメッセージの状態をトラッキングしている。この防護システムは新たにセッションが識別された時点で状態情報の新たなインスタンスを作成する。各メッセージは、ターゲットアプリケーションおよびセッションを識別している。あるメッセージが受信されると、防護システムはこのメッセージからそのアプリケーションおよびセッションを識別する。この防護システムは、そのメッセージのヘッダ情報内に格納されたポート番号に基づいてそのアプリケーションを、またそのメッセージ内でセッション情報が格納されている場所に関する識別アプリケーション向けの指示に基づいてそのセッションを識別することがある。あるアプリケーションの脆弱性指定基準は、当該アプリケーションに関連付けされたポート番号を指定し、かつ当該アプリケーションのメッセージの内部にセッション識別子の位置を記述することがある。さらに、あるアプリケーションの脆弱性指定基準は、あるメッセージの内部で、メッセージタイプの位置およびメッセージ境界の位置などの別の情報の位置を指定することがある。そのメッセージがあるセッションの最初である場合、防護システムは当該セッションに関する状態情報データ構造を割り当てることがある。あるアプリケーションの脆弱性指定基準は、メッセージ単位で格納されることが必要な情報に基づいてそのデータ構造を規定することがある。防護システムは、セッションの現行の状態を脆弱性指定基準によって規定された初期状態に設定することを含むこと場合がある、状態情報に対する初期化を行う。新たなメッセージを受信するたびに、防護システムはそのアプリケーションおよびセッションを識別し、当該のアプリケーションおよびセッションに関する状態情報を取り出し、次いでステートマシンエンジンを呼び出し、現行の状態および受信したメッセージによって指定されたイベントに基づいて実行するためのハンドラーを選択する。

一実施形態では、その防護システムは、単一のメッセージ単位として到着しないことがあるアプリケーションレベルのメッセージを取り扱う。単一のアプリケーションレベルのメッセージの複数メッセージ単位となった分散した到着は、ＴＣＰ輻輳制御、アプリケーションの指定メッセージ取扱い実現形態、その他の結果として起こることがある。例えば、あるＵＤＰサーバは単一のアプリケーションレベルのメッセージを受信するために複数の呼を発する。こうしたケースでは、防護システムは、アプリケーションレベルのメッセージに関して複数メッセージ単位の到着を認識する。セッション識別子またはメッセージタイプが単一のメッセージ単位で受信されない場合、またはハンドラーがその処理を完了できるだけの十分なアプリケーションレベルのメッセージが受信されていない場合は、防護システムは、そのアプリケーションレベルのメッセージをハンドラーが処理できるようになるまで、各メッセージ単位からなる必要な部分に関するコピーを作成する。防護システムは、部分的メッセージ情報をセッションごとに保存することが可能であり、このためにはセッションごとのバッファの割り当てが必要となることがあり得る。しかし、複数のセッションが同じソケットを通じて送られる場合は、防護システムは、部分的メッセージ情報を各ソケット単位で格納することが可能となり得る。ソケットは、典型的には、あるセッションに関する完全なメッセージが受信されてから、同じソケットを介して別のメッセージの任意の部分が受信されるという特徴を有している。セッション数と比べて存在するソケット数がより少ないことがあるため、セッションごとに情報を保存する際に割り当てを要するバッファはより少ないことがある。バッファは、そのセッション識別子が受信される前は１つのソケットだけに関連付けすることができる。セッション識別子を受信した後に、このバッファはそのセッションに関連付けさせることができる。

一般に、防護システムは、部分的に到着したフィールドを保存することが不要であるのみならず、受信済みのアプリケーションレベルのメッセージの部分全体を保存することも不要である。例えば、４バイトのセッション識別子のうちの２バイトが受信済みである場合、防護システムが保存を要するのは当該メッセージのうちこの２バイトのみである。防護システムは、アプリケーションレベルのメッセージ１つあたり１つのフィールド構文解析状態を使用し、どのフィールドが構文解析を受けているか、ならびに受信済みであるのが何バイトかをトラッキングすることがある。防護システムは、そのメッセージが悪用につながることがないと判定済みの場合であっても、各アプリケーションレベルのメッセージに関して構文解析中の現行のフィールドの構文解析状態を維持する。この状態が維持されていないと、アプリケーションレベルのメッセージの別の部分が新たなメッセージとして取り扱われることがあり得る。こうしたケースでは、アプリケーションの実際のメッセージ状態と防護システムのエミュレートしたメッセージ状態との間に不整合を生じさせるように攻撃者によってメッセージが巧みに作られている可能性がある。

防護システムは、順序が乱れて受信したアプリケーションレベルのメッセージが順序通りに処理できるようにするために、メッセージをバッファリングすることがある。例えば、ＵＤＰが使用される場合に、アプリケーションレベルのメッセージは順序が乱れて受信される可能性がある。防護システムは、そのアプリケーションに関する防護ポリシー内の指定に従ったシーケンス番号を使用する。さらに、いくつかのアプリケーションメッセージプロトコルによってアプリケーションレベルのメッセージの断片化および再構築が可能となる。これらの断片は、順序通りに受信される場合（例えば、ＴＣＰの場合）や、順序が乱れて受信される場合（例えば、ＵＤＰの場合）があり得る。防護システムは、順序通りに受信した断片を上述した部分的フィールド処理と同様の方式で取り扱うことができる。その断片を順序が乱れて受信した場合は、防護システムはこれらを保存してこれらを順序通りに処理することができる。

一実施形態では、その防護システムの原理は、メッセージプロトコルを強化するために適用することができる。例えば、メッセージプロトコルのある状態において認証処理を追加することによって、アプリケーションのセキュリティを改善することが望ましい。しかし、アプリケーションの開発者はこれを行うことに乗り気でないことがある。こうしたケースでは、防護システムと同様のシステム（例えば、認証システム）が実現される可能性がある。認証システムは、サーバ側とクライアント側とを有することがある。サーバ側は、状態、イベントおよびハンドラーの指定基準と、ステートマシンエンジンとを使用し、認証を起動させたときに適当な状態およびイベントを識別することになる。この状態およびイベントに関するハンドラーは、メッセージがアプリケーションに提供される前にクライアントに対してチャレンジを送ることが可能である。チャレンジを受信すると、認証システムのクライアント側はチャレンジが受信済みであることを検出し、適当な応答を送出することが可能である。クライアント側は、チャレンジを検出するために指定基準およびステートマシンエンジンを有することがある。サーバ側が応答を受信すると、サーバ側はその応答を検証しメッセージを適宜アプリケーションに提供することができる。より一般的には、メッセージプロトコル状態をトラッキングし、ターゲットアプリケーションによる処理以前に所望の処理を実施することができる汎用アーキテクチャが提供される。このアーキテクチャはクライアントおよびサーバに関して対称とすることがあるが、その指定基準については、サーバとこれに対するクライアントの処理ニーズが異なるため、非対称となる。この汎用アーキテクチャは暗号化スキーム、メッセージのログ処理、問題のデバッグ、等々を実現するために使用される可能性がある。

一実施形態では、その防護システムは、メッセージを処理するためのアプリケーションプログラミングインターフェース（「ＡＰＩ」）を装備することによってメッセージを阻止することがある。例えば、ｓｏｃｋレイヤＡＰＩの受信機能は、潜んでいる非装備の受信機能を呼び出し、次いでそのメッセージが含んでいるバッファを防護コンポーネントに渡すために装備されることがある。防護コンポーネントによってそのメッセージが脆弱性を悪用することになると判定された場合、この防護は、当該メッセージを廃棄する、すなわち通信セッションを解除することがあり、また装備された受信機能がエラーを返すことがある。そうでない場合は、装備された受信機能は、非装備の受信機能であったとした場合と同様にバッファを返すことがある。防護システムは、ＡＰＩの階層の様々なレベルにおいて、メッセージまたはメッセージの一部分を阻止するために使用されることがある。ＡＰＩの階層には、より低いレベルのＡＰＩを呼び出すＡＰＩが含まれており、一方このより低レベルのＡＰＩはさらにより低レベルのＡＰＩを呼び出している。アプリケーションのプログラマは、典型的には、最上位レベルのＡＰＩを呼び出すためのアプリケーションを開発する。例えば、あるアプリケーションは、顧客からの新たな注文を引き出すために顧客関係管理システム（「ＣＲＭ」）のＡＰＩから注文取得機能を呼び出す。この注文取得機能は、ヘッダ取得機能を呼び出し、さらにより低レベルの発注ＡＰＩのライン項目取得機能を反復して呼び出し、アプリケーションに戻すためにその注文情報を集計することがある。このライン項目取得機能は、ソケットレイヤＡＰＩの受信機能を呼び出し、顧客から送られてきた次行の項目のメッセージを取り出すことがある。ＣＲＭ ＡＰＩの注文取得機能は、この新たな注文を防護システムに渡すために装備されることがある。防護システムは、新たな注文パラメータを解析しかつこれにより脆弱性が悪用されることになるか否かを判定するためにハンドラーを有することがある。ここで防護システムは、脆弱性を悪用することになるパラメータを検出して補正するために使用されることがある。例えば、防護システムは、顧客からのある新たな注文が認証を受けることができるか否かを判定するために使用されることがある。否であれば、防護システムはこの新規注文を廃棄し、アプリケーションに対してエラーを返すことができる。したがって、防護システムは、様々な抽象レベルにおいてメッセージの意味を解析するために使用することができる。

図１は、一実施形態による防護システムを表したブロック図である。この防護システム１１０は、通信リンク１４０を介してクライアント１３０と接続されており、また、アプリケーション１２０に接続されている。これらの防護システムとアプリケーションは、同じコンピュータシステム上で動作すること、それぞれ別のコンピュータシステム上で動作すること、あるいはこれらの何らかの組み合わせで動作することがある。この防護システムは、脆弱性指定基準記憶装置１１１と防護コンポーネント１１２とを含んでいる。この脆弱性指定基準記憶装置は、各アプリケーションに対する脆弱性指定基準を包含している。通信リンクを介してクライアントからメッセージが受信されると、防護コンポーネントはそのメッセージが導かれる先のアプリケーション、ならびに当該アプリケーションの内部のセッションを識別する。防護コンポーネントは、当該アプリケーションに関する脆弱性指定基準に基づいて、当該セッションに関するメッセージ状態を遷移させる。脆弱性に対する悪用につながらないメッセージは、アプリケーションに直接受け渡される。これに対して、防護コンポーネントは、脆弱性を悪用することになるメッセージをドロップさせ、セッションの解除などの別の適当な措置を取ることがある。脆弱性指定基準記憶装置は、新たな脆弱性が発見されると、防護システムの動作を中断することなく、新規の指定基準を動的にロードおよびアンロードすることがある。

図２は、一実施形態による脆弱性指定基準内に規定されるメッセージプロトコルの一部分の状態図である。状態２１１〜２１５は、あるアプリケーションの当該脆弱性に関連するメッセージプロトコル状態を意味している。これらの状態は、そのアプリケーションのメッセージ状態のうちの１つの部分組である。ハンドラー２２１〜２２４は、あるセッションに関連付けされたメッセージ状態がメッセージが受信されるに連れてある状態から次の状態へと遷移する際に実施される措置の組を意味している。状態２１１は、セッションの初期状態であって、このセッションがＲＰＣバインドメッセージを待っている状態であることを示している。状態２１１にあるときにＲＰＣバインドメッセージを受信すると、防護システムは、ＲＰＣバインドハンドラー２２１を実行する。ＲＰＣバインドハンドラーはこのセッションの次の状態を、ＲＰＣバインド確認を待っている状態である状態２１２に設定するか、あるいはそのセッションの最終状態である状態２１５に設定する。状態２１２にあるときにＲＰＣバインド確認メッセージを受信すると、防護システムはＲＰＣバインド確認ハンドラー２２２を実行する。ＲＰＣバインド確認ハンドラーはＲＰＣ要求を待っている状態である状態２１３に遷移するか、あるいは最終状態である状態２１５に遷移する。状態２１３にあるときにＲＰＣ要求メッセージを受信すると、防護システムはＲＰＣ要求ハンドラー２２３を実行する。ＲＰＣ要求ハンドラーがそのメッセージの内容に基づいて脆弱性が曝露されると判定した場合は、その次の状態を、そのセッションを解除することを示す状態２１４に設定するか、さもなければ最終状態である状態２１５に設定する。状態２１４にあるときに解除要求が確認されると、防護システムはセッション解除確認ハンドラー２２４を呼び出し、セッションの解除を完了させると共に、最終状態である状態２１５に遷移する。ハンドラー２２１および２２２はそのメッセージがアプリケーションに送られることを許可することがあるが、ハンドラー２２３は次の状態が状態２１４であるときにはそのメッセージがアプリケーションに送られることを許可しない。

図３は、一実施形態による防護システムのアーキテクチャを表したブロック図である。この防護システムは、ポリシーローダー３０１と、アプリケーションディスパッチャ３０３と、セッションディスパッチャ３０４と、ステートマシンエンジン３０５と、インタープリタ３０６とを含んでいる。この防護システムはさらに、脆弱性指定基準記憶装置３０２と、アプリケーション／セッション状態記憶装置３０７とを含んでいる。ポリシーローダーは、脆弱性に対する防護ポリシーを受け取り、防護ポリシーを脆弱性指定基準に変換し、さらにこれを脆弱性防護記憶装置内に保存する。ポリシーローダーは、同じアプリケーションに関する脆弱性指定基準を自動式に結合させ、各アプリケーションが脆弱性指定基準を１つだけ有するようにすることがある。防護システムによって受信されたメッセージは先ず、アプリケーションディスパッチャによって処理される。アプリケーションディスパッチャはそのメッセージに関連付けされたポートをメッセージヘッダから識別し、次いで脆弱性指定基準記憶装置に対して当該ポート番号に関連付けされたアプリケーションを識別するように要求する。脆弱性指定基準記憶装置はアプリケーション識別子によって応答する。次いで、アプリケーションディスパッチャはこのアプリケーション識別子およびそのメッセージをセッションディスパッチャに転送する。セッションディスパッチャはそのメッセージに関連付けされたセッションを識別する。セッションディスパッチャは脆弱性記憶装置に対してそのアプリケーション識別子に関連付けされたセッション識別情報を提供するように要求する。脆弱性指定基準記憶装置はそのメッセージ内部のセッション識別子の位置を記述している情報によって応答しており、またさらにメッセージタイプの位置およびメッセージ境界および別のヘッダまたはペイロード記述情報を含むこともある。次いで、セッションディスパッチャはこの位置情報を用いてメッセージからセッション識別子を取り出す。セッションディスパッチャはさらに、そのメッセージを解析してメッセージに関連付けされたメッセージイベントを識別することがある。一実施形態では、メッセージタイプとイベントの間には一対一の対応関係が存在することがある。ステートマシンエンジンは、セッションディスパッチャから、アプリケーション識別子、セッション識別子、現行のイベント、およびメッセージを受け取る。ステートマシンエンジンは、アプリケーション識別子を脆弱性指定基準記憶装置に提供すると共に、当該アプリケーション識別子に関連付けされたステートマシントリプレットを要求する。ステートマシンエンジンはさらに、アプリケーション識別子およびセッション識別子をアプリケーション／セッション状態記憶装置に提供すると共に、関連付けされた状態情報を要求する。トリプレットおよび状態情報を受信した時点で、ステートマシンエンジンは現行の状態および現行のイベントとマッチングするトリプレットを検索する。マッチングが得られたら、ステートマシンエンジンはこのマッチングしたトリプレットに関連付けされたハンドラーを実行するようにインタープリタに指令する。インタープリタは、対応する防護ポリシーによって規定された措置を実施するハンドラーを実行する。この措置には、次の状態などの状態情報をアプリケーション／セッション状態記憶装置内に保存することを含むことがある。ハンドラーはさらに、アプリケーション／セッション状態記憶装置から情報（例えば、セッションの以前のメッセージを処理したハンドラーが保存した情報）を取り出すことがある。

防護システムをその上に実現させる計算デバイスは、中央演算処理装置、メモリ、入力デバイス（例えば、キーボードおよびポインティングデバイス）、出力デバイス（例えば、ディスプレイデバイス）、ならびに記憶デバイス（例えば、ディスク駆動装置）を含むことがある。メモリおよび記憶デバイスは、防護システムを実現させる命令を含むことがあるコンピュータ読み取り可能な媒体である。さらに、通信リンク上の信号などデータ伝送媒体を介してデータ構造およびメッセージ構造が保存または伝送されることがある。インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、またはポイントツーポイントのダイアルアップ接続など、様々な通信リンクが使用されることがある。

図３は、防護システムをその内部に実現させることがある適当な動作環境の一例を表している。この動作環境は、適当な動作環境の単なる一例であって、防護システムの利用法および機能の範囲に関する何らの限定を示唆することを意図したものではない。使用に適することがあるような、よく知られている別の計算システム、環境、および構成には、パーソナルコンピュータ、サーバコンピュータ、ハンドへルドまたはラップトップデバイス、ルータ、スイッチ、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、以上のシステムまたはデバイスのいずれかを含む分散型計算環境、その他が含まれる。

防護システムは、１つまたは複数のコンピュータまたは別のデバイスによって実行されるプログラムモジュールなどコンピュータ実行可能な命令の一般的コンテキストで記述されることがある。一般的に、プログラムモジュールは、識別のタスクを実施するか、あるいは識別の抽象データタイプを実現しているような、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、その他を含んでいる。典型的には、このプログラムモジュールの機能は、様々な実施形態において所望により結合されたり、分散されたりすることがある。「アプリケーション」という用語は、ドライバ、カーネルモードのコード、オペレーティングシステム、システムユーティリティ、ウェブサーバ、データベースサーバ、その他など、任意のタイプの実行ソフトウェアを意味している。

表１は、一実施形態の防護ポリシーの一部分を表している。この防護ポリシーは、特殊用途の言語を用いて開発されることがある。防護ポリシーは、アプリケーションおよびステートマシン情報を備えた第１の部分と、ハンドラーおよびペイロード命令を備えた第２の部分とを有している。先頭に「＃」を付けた行はコメントである。アプリケーション情報（行１〜５）は、位置およびポート情報を記述している。ステートマシン情報（行６〜２８）は、状態、イベント、およびトリプレットを記述している。ハンドラー（行４６〜６７）は実施すべき処理を規定している。ペイロード命令（行２９〜４５）は、アプリケーションのメッセージのフィールドを構文解析する方法を指定している。ペイロード命令は、悪用の検出に使用されるフィールドを規定するためにのみ必要である。これ以外のフィールドは、ひとまとめにしたり、フィールド構文解析中においてスキップさせることができる。ハンドラーは、理論的には任意のプログラミング言語で記述することが可能である。防護ポリシー自体を攻撃することを困難とさせるような言語を使用すべきである。こうした攻撃の防止に役立つように特殊用途のプログラミング言語が開発されている。表１のハンドラーでは、その言語は、ブール型、カウンタ（例えば、整数）、ならびにワードおよびバイトのアレイのデータタイプを使用している。この言語はさらに、メッセージのドロップ、セッションの解除、メッセージ長の決定、その他などの様々な演算を提供する。「＞＞ペイロード」という演算（例えば、行４９）は、指定されたペイロード命令に従ってペイロードを構文解析すること（例えば、このペイロードは「Ｐ＿ＲＰＣＲｅｑｕｅｓｔ」のバッファサイズである）を示している。この言語はさらに、ｉｆ−ｔｈｅｎステートメント、特殊用途のｆｏｒループ、その他などのステートメントを許容することがある。特殊用途のｆｏｒループは、反復式ペイロード構造のために使用される。一実施形態では、そのハンドラーは、実行時にインタープリタによって解釈される。

図４は、一実施形態のステートマシンエンジンの処理を表した流れ図である。このエンジンは現行のイベント、アプリケーション識別子、セッション識別子、およびメッセージを通過する。ブロック４０１において、このエンジンはアプリケーション識別子およびセッション識別子をアプリケーション／セッション状態記憶装置に提供する。ブロック４０２において、このエンジンはそのアプリケーション識別子およびセッション識別子に関する現行の状態をアプリケーション／セッション状態記憶装置から受け取る。ブロック４０３において、このエンジンはアプリケーション識別子を脆弱性指定基準記憶装置に提供する。ブロック４０４において、このエンジンはアプリケーション識別子に関するステートマシントリプレットを脆弱性指定基準記憶装置から受け取る。ブロック４０５〜４０７において、このエンジンはトリプレットが現行の状態および現行のイベントとマッチングするか否かを判定するようにループ動作する。ブロック４０５において、このエンジンは次のトリプレットを選択する。判断ブロック４０６において、トリプレットのすべてがすでに選択され終っている場合には、このエンジンは終了となり、そうでなければこのエンジンはブロック４０７から継続される。トリプレットの組には、現行の状態および現行のイベントとマッチングするトリプレットが他にない場合に実行すべきハンドラーを識別するデフォルトトリプレットを含むことがある。さらに、トリプレットの状態およびイベントは、そのトリプレットとマッチングする状態およびイベントを規定する正規表現とすることがある。判断ブロック４０７において、トリプレットの状態が現行の状態とマッチングしており、かつそのトリプレットのイベントが現行のイベントとマッチングしている場合には、このエンジンはブロック４０８から継続され、そうでなければこのエンジンは次のトリプレットを選択するためにブロック４０５までループ動作する。ブロック４０８において、このエンジンは、ハンドラー、アプリケーション識別子、セッション識別子、現行のイベント、およびメッセージを通過するインタープリタを呼び出す。次いで、このエンジンは終了となる。

図５は、一実施形態による脆弱性指定基準の試験を表したブロック図である。この防護システム５１０は、試験を受ける脆弱性指定基準５１１を含んでいる。この防護システムはさらに、図３のアプリケーションディスパッチャ、セッションディスパッチャ、ステートマシンエンジン、およびインタープリタに対応する防護コンポーネント５１２を含んでいる。この防護システムは、その脆弱性が脆弱性指定基準によって表現されているアプリケーション５０１にメッセージを提供する。ネットワークシミュレータ５０２はメッセージを防護システムに引き渡している。このメッセージは、アプリケーションに提供される典型的なメッセージシーケンスから収集されたネットワークデータ５０３から取り出されることや、代表的なトラフィックの合成試験スイート（synthetic test suite）とすることがある。この防護システムはアプリケーションに対するパッチではないため、その試験が簡略化される。詳細には、防護システムに関連する副作用は、典型的なアプリケーションの副作用の場合と比べてより容易に分離することができる。アプリケーションの観点からすると、この防護システムはメッセージを提供するかメッセージをドロップするかのいずれかである。そのネットワークデータが脆弱性を曝露させる一連のメッセージを含まない場合は、メッセージはすべて防護システムを通過させてアプリケーションに提供すべきである。防護システムによってあるメッセージが廃棄された場合、このことは、脆弱性指定基準に関する問題点を指摘している場合や、脆弱性の曝露が検出されたことを示す場合がある。

図６は、一実施形態による脆弱性指定基準の作成を表したブロック図である。脆弱性指定基準は、アプリケーションに対するメッセージプロトコルステートマシンの標準的な規定に基づいて自動式にまたは半自動式に作成されることがある。指定基準作成器６１０は、標準規定を用いて規定されたあるアプリケーション向けのメッセージプロトコルステートマシン記述６０１を入力する。指定基準作成器はステートマシンを処理して適当な脆弱性指定基準６０２を出力する。指定基準作成器は、脆弱性ステートマシン識別コンポーネント６１１と、ハンドラー作成コンポーネント６１２と、指定基準生成コンポーネント６１３とを含んでいる。脆弱性ステートマシン識別コンポーネントはユーザ入力を受け取り、そのステートマシンのうちの脆弱性を曝露させる部分を識別する。このユーザ入力は、脆弱性の曝露につながる状態を選択することがあり、また各状態が如何にしてかつどの様な場合に脆弱性を曝露させるかを示すために状態の様々な条件を提供することがある。例えば、あるメッセージが脆弱性を曝露させるのは、前のメッセージがある種の内容を含んでいた場合だけであることがある。ハンドラー作成コンポーネントは、ユーザ入力に基づいてハンドラーを自動式で作成することがある。指定基準生成コンポーネントは、脆弱性ステートマシンおよびハンドラーから、脆弱性指定基準や防護ポリシーを作成する。

防護システムの具体的な実施形態について例示を目的として本明細書に記載してきたが、当業者であれば、本発明の精神および趣旨を逸脱することなく様々な修正を実施できることを理解されよう。例えば、メッセージのペイロードが暗号化されている場合、防護システムはアプリケーションに暗号解読キーを要求することがある。次いで、防護システムはメッセージを暗号解読し、暗号解読したメッセージを処理することができる。この防護システムは、アプリケーションに対して暗号未解読の形態でメッセージを提供することができる。別法として、その防護システムは、そのアプリケーションのキー保管庫（ｖａｕｌｔ）から暗号解読キーを取り出すことがある。暗号解読キーはまた、システム管理者やキーエスクローシステムによって防護システムに提供されることもある。別の例として、アプリケーションにポートが動的に割り当てられている場合、こうしたポートを検出しこの当該アプリケーションに対するポートを脆弱性指定基準記憶装置によって登録するように脆弱性指定基準を開発することができる。この防護システムについて、主にメッセージベースのプロトコルのコンテキストで記述してきたが、この防護システムの原理はさらに、ストリームベースのプロトコルにも適用することができる。さらに、この防護ポリシーは有限のステートマシンの代わりに正規表現を用いることもある。この防護システムは、参照により本明細書に組み込むことにする「METHOD AND SYSTEM FOR DYNAMIC SYSTEM PROTECTION」と題する２００４年２月２３日に提出された特許文献１（整理番号第４１８２６．８０１８ＵＳ）に記載されている技法と一緒に使用することができる。この出願に記載されているように、防護ポリシーは、アプリケーションに適用されたパッチに応じて自動式に有効化または無効化することができる。防護システムは、アプリケーションの呼び出し用アプリケーションプログラミングインターフェース（「ＡＰＩ」）に基づいて脆弱性の悪用の試みを検出するために使用することができる。ＡＰＩは、プログラムがこれを介してアプリケーションのサービスにアクセスすることができるインターフェースを提供する。このインターフェースは、プログラムがアプリケーションと通信するための通信プロトコルを規定している。したがって、「通信プロトコル」という用語はコンポーネント間の通信に関する手続きおよび規則を示しており、ＩＳＯプロトコルスタックのプロトコルに限定しない。したがって、本発明は添付の特許請求の範囲による以外の限定を受けない。

一実施形態による防護システムを表したブロック図である。 一実施形態による脆弱性指定基準内に規定されるメッセージプロトコルの一部分の状態図である。 一実施形態による防護システムのアーキテクチャを表したブロック図である。 一実施形態によるステートマシンエンジンの処理を表した流れ図である。 一実施形態による脆弱性指定基準の試験を表したブロック図である。 一実施形態による脆弱性指定基準の作成を表したブロック図である。

符号の説明

１１０ 防護システム
１１１ 脆弱性指定基準記憶装置
１１２ 防護コンポーネント
１２０ アプリケーション
１３０ クライアント
１４０ 通信リンク
２１１ ＲＰＣバインドを待つ状態
２１２ ＲＰＣバインド確認を待つ状態
２１３ ＲＰＣ要求を待つ状態
２１４ セッションを解除する状態
２１５ 最終状態
２２１ ＲＰＣバインドのハンドラー
２２２ ＲＰＣバインド確認のハンドラー
２２３ ＲＰＣ要求のハンドラー
２２４ セッション解除確認のハンドラー
３０１ ポリシーローダー
３０２ 脆弱性指定基準記憶装置
３０３ アプリケーションディスパッチャ
３０４ セッションディスパッチャ
３０５ ステートマシンエンジン
３０６ インタープリタ
３０７ アプリケーション／セッション状態記憶装置
５０１ アプリケーション
５０２ ネットワークシミュレータ
５０３ ネットワークデータ
５１０ 防護システム
５１１ 試験脆弱性指定基準
５１２ 防護コンポーネント
６０１ メッセージプロトコルステートマシン
６０２ アプリケーション脆弱性指定基準
６１０ 指定基準作成器
６１１ 脆弱性ステートマシン識別
６１２ ハンドラー作成
６１３ 指定基準生成

Claims (14)

1. コンピュータシステムにおいて、コンポーネントとの複数の通信が当該コンポーネントの脆弱性を暴露する時点を識別するための方法であって、前記コンポーネントは当該コンポーネントが通信を受信すると遷移する複数の通信プロトコル状態を有する通信プロトコルを使用するコンポーネントであり、前記方法は、
   ある通信プロトコル状態から別の通信プロトコル状態への遷移に関連する通信の特徴と共に前記コンポーネントの前記複数の通信プロトコル状態の少なくとも一部分を指定しかつ特定の通信シーケンスを利用した前記脆弱性が暴露される時点の通信プロトコル状態を示す、当該脆弱性の暴露から独立している指定基準を提供するステップと、
   前記コンポーネントに対する複数の通信を受信するステップと、
   前記受信された通信の各々が前記コンポーネントによって処理される前に、
   前記コンポーネントの現在の通信プロトコル状態を判定し、
   前記提供された指定基準および前記受信された通信の１つのメッセージに基づいて次の通信プロトコル状態を判定し、
   前記次の通信プロトコル状態が脆弱性を暴露する通信プロトコル状態であると示される場合に、前記受信された通信を前記コンポーネントへ提供せず、
   前記次の通信プロトコル状態が脆弱性を暴露する通信プロトコル状態であると示されない場合に、前記受信された通信を前記コンポーネントへ提供し、
   前記現在の通信プロトコル状態を前記次の通信プロトコル状態にセットする、ステップと
   を含むことを特徴とする方法。
2. 前記提供された指定基準は通信の処理を制御するためのステートマシンを規定していることを特徴とする請求項１に記載の方法。
3. 前記ステートマシンは、前記通信プロトコルの複数の通信プロトコル状態と、通信プロトコル状態間での遷移イベントとを規定していることを特徴とする請求項２に記載の方法。
4. 前記指定基準は前記通信プロトコル状態間での遷移の際に実施すべき措置を指定していることを特徴とする請求項２に記載の方法。
5. 前記判定は、前記指定基準、現在の通信プロトコル状態および現在のイベントを入力し、前記現在の通信プロトコル状態および前記現在のイベントに対して前記指定基準内で識別されるハンドラーを選択し、かつある措置を実施するように前記ハンドラーの起動を指示しているステートマシンエンジンによって実施されていることを特徴とする請求項４に記載の方法。
6. 前記現在の通信プロトコル状態は各コンポーネント単位で保存されていることを特徴とする請求項１に記載の方法。
7. 前記現在の通信プロトコル状態は各セッション単位で保存されていることを特徴とする請求項１に記載の方法。
8. 前記コンポーネントは複数のセッションを取り扱っており、かつ前記通信プロトコル状態を判定することは１つのセッションの通信のみに基づいていることを特徴とする請求項１に記載の方法。
9. アプリケーションにメッセージが送られる結果として当該アプリケーションの脆弱性が曝露される時点を検出するシステムであって、メモリとプロセッサとを備え、
   前記メモリは、
   あるメッセージが前記アプリケーションの特定の通信シーケンスを利用した前記脆弱性を曝露させる時点を示すステートマシンを規定しかつ前記アプリケーションの前記脆弱性の曝露を防止するために取るべき措置を規定している前記アプリケーション向けの指定基準であって、ここで、前記ステートマシンは前記アプリケーションによって使用される通信プロトコルの１つのメッセージを処理すると遷移する複数の通信プロトコル状態を指定しており、当該脆弱性の暴露から独立している指定基準、
   前記ステートマシンによって表された前記アプリケーションの現在の状態を保存している状態ストア、および
   プログラムを記録しており、
   前記プログラムは、前記プロセッサを、
   前記アプリケーションに対する複数のメッセージを受信し、
   前記アプリケーションに関する前記ステートマシンの現在の通信プロトコル状態を取り出し、かつ
   前記取り出された現在の通信プロトコル状態にありかつ当該メッセージが受信されたときに実施すべき措置を前記アプリケーションに関する前記指定基準から識別するエンジンと
   として機能させることを特徴とするシステム。
10. 前記状態ストアは各セッション単位で状態情報を保存することを特徴とする請求項９に記載のシステム。
11. あるアプリケーションに関して複数の脆弱性が規定されている場合、前記脆弱性を指定するために単一の指定基準が使用されていることを特徴とする請求項９に記載のシステム。
12. あるメッセージの一部分を前記メッセージの全体が受信されるまで保存している記憶装置を含むことを特徴とする請求項９に記載のシステム。
13. 前記メッセージの前記一部分は各ソケット単位で保存されていることを特徴とする請求項１２に記載のシステム。
14. コンピュータシステムを制御してメッセージがアプリケーションの脆弱性を暴露する時点を識別するためのプログラムを記録したコンピュータ読み取り可能な記録媒体であって、前記アプリケーションは当該アプリケーションがメッセージを受信すると遷移する複数のメッセージプロトコル状態を有するメッセージプロトコルを備え、前記プログラムは、前記コンピュータシステムに、
    前記アプリケーションの前記メッセージプロトコル状態の少なくとも一部分を指定し、かつ前記メッセージプロトコル状態の前記指定された部分の内部で前記アプリケーションの特定の通信シーケンスを利用した前記脆弱性が暴露される時点を指示している、当該脆弱性の暴露から独立している指定基準を提供するステップであって、ここで前記提供された指定基準はメッセージの処理を制御するためのステートマシンを規定しており、前記ステートマシンは複数のメッセージプロトコル状態および状態間での遷移イベントを規定している、ステップと、
    前記アプリケーションに対する複数のメッセージを受信するステップと、
    前記アプリケーションの前記メッセージプロトコル状態の前記指定された少なくとも一部分、現在のメッセージプロトコル状態及び前記前記受信されたメッセージに基づいて受信された１つのメッセージが前記アプリケーションの前記脆弱性を暴露するか否かを判定するステップと、
    前記脆弱性を暴露すると判定されたときは前記受信された１つのメッセージを前記アプリケーションに提供せず、前記脆弱性を暴露しないと判定されたときは前記受信された１つのメッセージを前記アプリケーションに提供するステップと
    を実行させることを特徴とするコンピュータ読み取り可能な記録媒体。

Images