JP4789933B2

JP4789933B2 - セキュアーソフトウェアを開発し、テストし、監視するための装置および方法

Info

Publication number: JP4789933B2
Application number: JP2007515157A
Authority: JP
Inventors: ブライアンチェス，; アーサードウ，; ショーンフェイ，; ロジャーソーントン，
Original assignee: フォーティファイソフトウェア，エルエルシー
Priority date: 2004-06-04
Filing date: 2005-05-12
Publication date: 2011-10-12
Anticipated expiration: 2025-05-12
Also published as: US20070240138A1; US9400889B2; JP2008502046A; KR20070043707A; EP1756708A4; EP1756708A1; KR101150653B1; WO2005121953A1

Description

発明の簡単な説明

[0001]本発明は、一般的には、ソフトウェアセキュリティーに関する。より詳細には、本発明は、ソフトウェアの開発、テスト、および、配置中に、ソフトウェアセキュリティー脆弱性を識別するための総合的な技術に関する。

発明の背景

[0002]ビジネスは、益々、情報技術に依存しつつある。情報システムは、広範囲に分散するネットワークを介して、益々、より複雑になり、より高性能になり、互いに接続され、そして、パートナーおよび顧客に開放的にアクセスできるようになりつつある。ビジネス環境は、益々、直接会って対話するよりも匿名の電子トランザクションへ大きくシフトしつつある。ソフトウェア開発自体が、海外開発制度および企業内共同コンピューティングによって、より分散化されつつある。これらの傾向は、悪用および無許可のアクセスからディジタルデータを団体が保護および防御する能力を弱める。

[0003]今日配置される主たるビジネスに不可欠なプリケーションのほぼすべてが、違法に利用されてビジネスまたはそれが管理する資産に大きな損害を与える可能性がある脆弱性を含む。これらの脆弱性は、アタッカーの利益または悪意のある意図のために、重要な情報を盗み、コンピュータシステムを妨害し、あるいは、処理に悪影響を与えるのに利用されることがある。

[0004]経験豊富なハッカーまたはルージュインサイダーにとって、この目的のためにソフトウェアを巧みに操作することは、オンラインで得ることのできる様々な情報およびツールによって、特に、容易なものとなる。アタッカーの最も大きな好機は、大きなビジネスアプリケーションにおける脆弱性をただ単に見つけ出すことである。さらに悪いことには、ファイアウォールのような主流のコンピュータセキュリティーソリューションは、露出されるという前提に基づくものであり、脆弱なソフトウェアは、外部の脅威からそれを隔離することによって、防御されることがある。ビジネス要件は、いくつかのビジネスに不可欠なアプリケーションが本当に隔離されることを強いる。ほとんどのものは、データ転送インタフェース、リモートプロシージャコール、および、内部および遠隔のユーザを介して、多くのアクセスポイントを有する。ファイアウォールおよびその他のネットワーク指向セキュリティーソリューションは、ビジネスに不可欠なアプリケーションが必要とするような種類のアクセスを阻止するようには構成されていない。実際に、今日のビジネス機能は、このアクセスに大きく依存しているので、これを拒絶されると、機能することができない。例えば、株式市場は、株式仲買人から取引所へのリンクなしに取引を行うことはできず、サプライチェーンは、供給者と生産者との間に流れる情報なしでは破綻し、そして、電気通信は、ビジネスの基盤をなすネットワークまたは課金システムを制御するコンピュータに携帯電話を接続する能力なしでは消滅する。アタッカーは、システムを危険にさらすのに毎日これらの事実を利用する。しかしながら、前提を裏返せば、真の欠陥は、脆弱なソフトウェアは、ともかくも非脆弱なものにすれば、なんとか防御される可能性があるということである。

[0005]このような背景を仮定すれば、当然ながら、それ自体に疑問が生じる。すなわち、なぜネットワークベースコンピュータセキュリティーソリューションが、明らかにソフトウェア問題であることに適用されるのか。１つの答えは、ほとんどの情報セキュリティー専門家は、ネットワークセキュリティー背景を有し、内容のないオペレーション上のセキュリティー問題の解決方法を展開していることであり、コアソフトウェア開発プロセスと向き合うための時間をほとんどとらない。それと同時に、アプリケーション開発者は、セキュリティーを考慮する余裕をほとんど持つことなく、厳しい納期までに新しい特徴を製作することに対して報酬を与えられる。一人の人間が、アプリケーション自体のセキュリティー要素に責任を持つことはめったにないことである。一般的な業務は、開発は、ビジネスに不可欠なアプリケーションを出荷することであり、そして、ネットワークオペレーションチームが、それを保護することであった。これらの役割の二分化は、アタッカーに驚くべき利益をもたらす。なぜなら、ソフトウェアセキュリティーに、より正確には、ビジネスに不可欠なアプリケーションの危険性に真に経験豊富であり、かつ専念している者は、彼らだけであるからである。

[0006]ソフトウェア開発の中心およびその周辺にいる当事者は、ソフトウェアセキュリティーに関して何かをなさなければならないことを次第に認識しつつある。それにもかかわらず、理路整然とした現実的なソリューションは、いまだに認識されていない。ソリューションを認識するのを困難にしているいくつかの要因が存在する。例えば、ソフトウェアセキュリティー脆弱性は、数千行のコード全体に存在する可能性がある微妙な論理的な誤りであり、適切な作業によって正確に検出することを極端に困難にしている。一見して、技術的なチャレンジは、このようなソリューションをコンパイラかまたはニッチ開発ツールにより類似しているように思わせる。しかしながら、大きなソフトウェア開発ツールベンダーは、セキュリティーを彼らの提供品の中核にしていない。彼らの顧客基盤は、依然として、特徴および機能の製作をどのようにして改善するかに大きく集中しており、ベンダーの内部チームは、変化するパラダイムを容易に認識することができずに、彼らの単一目的商品の特徴セットを改善することに努力している。これは、伝統的な革新者のジレンマである。さらに、大量の開発ツールを提供するプロバイダーは、リスク管理システムが必要とする企業型ソリューションを供給することに熟達しておらず、あるいは、そのようなソリューションを提供するのに必要な価格を維持することに熟達していない。実際に、開発ツール価格の現状は、一般的には、セキュリティー共同体が開発者指向ソリューションを構築するのをためらわせてきた。

[0007]開発ツールランドスケープに固有の弱点の他に、ソフトウェアセキュリティーは、絶え間なく変化する分野における特別な専門知識を必要とする。問題は、コードをスキャンするための技術を見つけ出すことに関するだけでなく、これらの脆弱性を検出するためのルールを生成しかつ絶えず更新することを含む。ルールを提供することは、研究およびリアルワールドアーキテクチャーの絶え間なく成長する本体、フレームワーク、使用パターン、および、ビジネスに不可欠なアプリケーションに脆弱性を発生させるその他の多くの要因に関する専門的な知識を必要とする。例えば、オペレーティングシステムまたはライブラリアプリケーションプログラムインタフェース（ＡＰＩ）がリリースされるたびに、セキュリティー脆弱性を発生させる新しい事項が発表される。ベンダーは、これらの境界のないマルチプラットフォームアーキテクチャーを考慮に入れたソリューションを提供しなければならない。

[0008]最後に、ソフトウェアセキュリティーが単一ポイントソリューションによって達成できることは考えられない。同様に、ソフトウェアセキュリティーが開発者レベルだけにおいて解決できることは考えられない。ソフトウェアセキュリティーは、主として、リスク管理問題である。このような問題を解決することは、長期にわたって収集された詳細な情報を必要とする。それは、これまでと同様に創造力に富むものにソフトウェア開発者を維持するアプローチ、さらには、開発、テスト、および、配置中に管理するために、セキュリティー計量を可視化するアプローチを必要とする。それは、管理者および団体のための企業ソフトウェア型ソリューションを必要とする。

[0009]上述したことに鑑みて、ソフトウェアセキュリティーのための改善された技術を提供することは、極めて望ましいことである。

発明の概要

[0010]セキュリティー脆弱性に関してプログラム命令を解析する方法は、セキュリティー脆弱性を識別するために、プログラム命令の開発段階において静的な解析をプログラム命令に施すことを含む。セキュリティー脆弱性は、プログラム命令のテスト段階においてセキュリティーテストをプログラム命令に施すのに使用される。セキュリティー脆弱性は、プログラム命令の開発段階においてプログラム命令に適用するためのセキュリティー監視基準を開発するために、解析される。

[0011]添付の図面を参照して以下の詳細な説明を理解することによって、本発明をより完全に理解することができる。

[0019]図面全体を通して、類似する符号は、類似する部分を参照する。

発明の詳細な説明

[0020]図１は、本発明の実施形態に基づいて構成された装置１００を示す。装置１００は、バス１０６を介して一組の入出力装置１０４に接続された中央演算処理装置１０２を含む。一例として、入出力装置は、キーボード、マウス、コンピュータモニター、プリンターなどを含んでもよい。また、ネットワークインタフェース１０８が、バス１０６に接続され、そのネットワークインタフェース１０８は、ネットワーク１１０とインタフェースをとるための標準的な装置を使用し、そのネットワーク１１０は、ローカルエリアネットワーク、イントラネット、インターネットなどであってもよい。

[0021]さらに、メモリー１１２が、バス１０６に接続される。メモリー１１２は、本発明のオペレーションを実施するための一組の実行可能な命令を記憶する。一実施形態においては、実行可能な命令は、３つの主たるモジュール、すなわち、セキュリティー開発モジュール１１４、セキュリティーテストモジュール１１６、および、セキュリティー監視モジュール１１８を含む。

[0022]セキュリティー開発モジュール１１４は、ソフトウェアの構造に固有のセキュリティー脆弱性を識別するために、ソフトウェアの静的解析を助けるための実行可能な命令を含む。ソフトウェアは、プログラム命令を含む。以下で説明するように、本発明は、多種多様なプログラム命令フォーマットに有効である。例えば、プログラム命令フォーマットは、様々なソースフォーマットまたは実行可能なコードフォーマット、様々なマシン命令フォーマット、および／または、様々なプログラム環境設定ファイルフォーマットであってもよい。プログラム命令は、様々なソフトウェアアプリケーションを形成する。一組のソフトウェアアプリケーションは、ソフトウェアシステムを定義し、そのソフトウェアシステムが、以下で説明されるように、本発明において解析される。一実施形態においては、セキュリティー開発モジュール１１４は、インタフェースモジュール１２０、共通フォーマット生成器１２２、セキュリティー開発ルール１２３、解析エンジン１２４、および、レポート生成器１２６を備えて実施される。

[0023]セキュリティーテストモジュール１１６は、セキュリティー脆弱性に関してソフトウェアのオペレーションをテストするための実行可能な命令を含む。好ましくは、セキュリティーテストモジュール１１６は、それのテストプロトコルを洗練するために、セキュリティー開発モジュール１１４によって収集された情報に頼る。一実施形態においては、セキュリティーテストモジュール１１６は、攻撃マネージャーモジュール１２８、攻撃データベース１３０、セキュリティーテストルール１３１、障害注入モジュール１３２、および、テストレポート生成器１３４を備えて実施される。

[0024]セキュリティー監視モジュール１１８は、セキュリティー脆弱性を識別するために、ソフトウェアの実行を監視するための実行可能な命令を含む。好ましくは、セキュリティー監視モジュール１１８は、セキュリティー脆弱性を識別するために、プログラムのローカルな実行および関連するプログラムのグローバルな実行に関連する情報に頼る。一実施形態においては、セキュリティー監視モジュール１１８は、センサー挿入モジュール１３６、セキュリティー監視ルール１３７、監視解析モジュール１３８、および、監視レポート生成器１４０を備えて実施される。

[0025]図１の実行可能なプログラムの構成は、典型的な例として示されたものである。これらのモジュールはどのような形で組み合わせられてもよく、また、どのような形でも、例えば、ネットワークを介するような形で、実行されてもよいことがわかるはずである。実際に、本発明の多くの実施形態においては、これらのコンポーネントは、ネットワーク全体に分散される。さらに、個々のサブモジュールによって実行されるオペレーションは、あらゆる形で組み合わせられてもよい。

[0026]本発明の主要な処理オペレーションに言及したので、ここで、これらの主要な処理オペレーションについて詳細に説明する。図１に示されるように、セキュリティー開発モジュール１１４は、インタフェースモジュール１２０を含む。インタフェースモジュール１２０は、インタフェースオペレーションをハンドルするための実行可能なコードを含む。例えば、インタフェースモジュールは、コマンドライン、プルダウンメニュー、ＩＤＥプラグインなどを介して、ユーザとの対話をハンドルする。また、インタフェースモジュールは、システムのその他の実行可能なプログラムと対話し、それらのプログラムには、セキュリティーテストモジュール１１６およびセキュリティー監視モジュール１１８が含まれる。

[0027]図２は、セキュリティー開発モジュール１１４のその他の実行可能なモジュールに関連する主要な処理オペレーションを示す。図２に示される第１の処理オペレーションは、ソースまたは実行可能なコードを共通フォーマットに変換することである（２００）。このオペレーションは、共通フォーマット生成器１２２によって実施されてもよい。共通フォーマット生成器１２２は、解析されるべきすべての階層のアプリケーションのすべてのソースファイルまたは実行可能なコードファイルを共通フォーマットに変換する。ここで開示される例としての共通フォーマットは、ＮｏｒｍａｌｉｚｅｄＳｙｎｔａｘＴｒｅｅ（ＮＳＴ）フォーマットと呼ばれる。

[0028]そして、アプリケーションシステムモデルが、共通フォーマットから得られる（２０２）。同様に、共通フォーマット生成器１２２が、このオペレーションを実行してもよい。より詳細には、実行可能なコードは、ＮＳＴファイルからアプリケーションの共通モデルを生成するのに使用される。

[0029]そして、データフロー解析が、システムモデルに対して実行され、セキュリティー脆弱性が、識別される（２０４）。解析エンジン１２４が、このオペレーションを実施するのに使用されてもよい。解析エンジン１２４は、ユーザ入力が危険な機能またはコンストラクに到達する可能性があるプログラム中の予想実行パスを識別する。解析エンジン１２４は、セキュリティー開発ルール１２３を呼び出す。典型的には、セキュリティー開発モジュール１１４が、一組のセキュリティー開発ルール１２３とともに配置される。これらのルールは、ネットワーク１１０に接続されたリモートコンピュータから定期的に更新されてもよい。供給されたこれらのルールに加えて、ユーザは、特定のアプリケーションに合わせて特別のセキュリティー開発ルールを作成してもよい。解析エンジン１２４は、独立した計算処理カーネルであり、したがって、それは、多種多様な一組の標準的なおよびカスタマイズされたセキュリティー開発ルール１２３とともに使用されてもよい。

[0030]解析エンジン１２４によって識別されたセキュリティー脆弱性は、ユーザおよび関連するモジュールにレポートされる（２０６）。レポート生成器１２６が、このオペレーションを実施するのに使用されてもよい。

[0031]セキュリティー開発モジュール１１４は、スタックバッファー、汚染された変数、ＳＱＬインジェクション、および、顧客定義セキュリティー欠陥のようなセキュリティー脆弱性を見つけ出すために、一種の意味解析を複数の階層および言語にわたって実行する。階層は、オペレーティングシステムから、データベース、ユーザインタフェースへのアプリケーションサーバー、Ｊａｖａ、Ｃ／Ｃ＋＋、ＨＴＭＬ、ＪＳＰ、および、ＰＬ／ＳＱＬを含む複数の言語に及ぶアプリケーションにわたる。本発明による多種多様なプログラム命令フォーマットおよび複数のソフトウェアアプリケーションを含むシステムの解析は、従来技術によるシステムよりも大きく進歩したものである。

[0032]本発明のセキュリティー開発モジュール１１４は、市販されている総合開発環境内に組み込まれてもよく、したがって、警告の調査およびセキュリティーエラーの除去は、エディット−コンパイル−デバッグというソフトウェア開発プロセスに含まれる自然なこととなる。

[0033]図１に示されるように、セキュリティー開発モジュール１１４は、解析エンジン１２４とともに実施されてもよい。好ましくは、解析エンジン１２４は静的解析を実行する。静的解析は、ソフトウェアを実行することなくそのソフトウェアを解析するための技術である。静的解析は、極めて複雑であることに昔から悩まされてきた。特に、静的解析は、リアルワールドソフトウェアに適用されたときに、多くの嫌疑を発生させ、あるいは、結果を解釈するのが難しいと言われてきた。

[0034]ソフトウェアセキュリティーオペレーションにおいて静的解析を使用することに関連したいくつかのチャレンジが存在する。第１に、グローバルデータフロー静的解析技術および制御フロー静的解析技術の両方が、正確さを提供するために使用されなければならない。第２に、無数の言語およびフレームワークは、ハンドルされなければならない特殊なケースをもたらす。第３に、セキュリティー解析は、大きな一組のアプリケーション特有脆弱性を取り扱うために、拡張可能なものでなければならない。第４に、セキュリティー解析は、特定の脆弱性クラスの意味論的表現を定義するために、攻撃の研究を必要とし、かつ、それらの攻撃は時間とともに変化するので、それらの研究は最新のものに維持されなければならない。最後に、どのような解析も、現実的な商品要件によって制約されるはずである。商業的環境において満足しなければならない２つの最も厳しい要件は、スケーラビリティーおよびコードアクセスである。スケーラビリティーに関しては、解析は、開発者のデスクトップにおいて極めて小さなオーバーヘッドで動作しなければならず、しかも、徹底的な監査において良好に動作しなければならず、かつ、膨大なコードベース全体にわたって精査しなければならない。さらに、グローバル解析は、多くの場合、コードの全体にアクセスすることなく円滑に実施されなければならない。

[0035]本発明は、従来技術に存在するこれらのチャレンジを解決するものである。セキュリティー開発モジュール１１４は、ソフトウェアセキュリティー問題だけに指向された新しい形態の静的解析を提供する。セキュリティー開発モジュール１１４は、ソフトウェアセキュリティーを改善するのに即座に使用することのできる有益な情報を提供する。さらに、それは、テスト段階および監視段階において違法に利用される有益な情報を提供する。

[0036]これらのオペレーションは、例を参照してより完全に理解される。以下の例は、簡単な２階層アプリケーションのためのセキュリティー開発モジュールによって実行されるステップを示す。以下の例は、それがコード脆弱性を識別するのに十分な入力を提供する点において完全なものである。この例は、アプリケーションを実際に実行するためにさらなる標準的なツール、サポートロジック、および、環境設定ファイルが必要とされるという点においては不完全なものである。これらのさらなる要素は、当分野において標準的なものであり、したがって、さらに詳細には説明しない。

[0037]サンプルアプリケーションは、ＪａｖａサーブレットおよびＰＬ／ＳＱＬパッケージからなる。このアプリケーションの目的は、口座残高をユーザに表示することである。アプリケーションは、以下のように動作する。Ｊａｖａサーブレットは、“ａｃｃｔ”という名前のパラメータを含む「ＨＴＴＰＰＯＳＴ」要求を受け入れる。これは、典型的には、ユーザがウェブページ上のフォームに書き込んで発行したときにウェブブラウザによって生成されるＨＴＴＰ要求の種類である。“ａｃｃｔ”パラメータは、例えば、ドロップダウンリストから口座名を選択するユーザによって設定されてもよい。サーブレットは、“ａｃｃｔ”パラメータの値をデータベースクエリーへ渡す。クエリーは、“ＡＣＣＴ．ｇｅｔ＿ｂａｌａｎｃｅ”という名前のデータベース内に記憶されたプロシージャを呼び出す。記憶されたプロシージャは、ＳＱＬクエリーをコンストラクトするために、サーブレットから渡されたパラメータを使用する。クエリーは、“ＡＣＣＯＵＮＴＳ”という名前のデータベーステーブルを調査する。それは、渡された口座名に一致する行の“ｂａｌａｎｃｅ”列内に存在する値を戻す。記憶されたプロシージャは、残高値をサーブレットに戻し、そして、サーブレットは、その残高値をユーザに戻す。

[0038]悪意のあるユーザは、見る権限を与えられていない口座残高を彼らが見るために、アプリケーションの脆弱性を違法に利用する可能性がある。脆弱性は、単純なものである。すなわち、アプリケーションは、ユーザが要求した口座番号の残高を見る許可を彼らが有しているかどうかを決して確かめることはしない。この種の脆弱性は、貧弱に書かれたウェブベースアプリケーションではよくあることである。問題は、データフローによって理解できる。すなわち、ユーザによって提供される“ａｃｃｔ”値は、検査されずにデータベース内のＳＱＬクエリーに流れ込む。このクラスの脆弱性は、「ＳＱＬインジェクション」として既知である。なぜなら、悪意のあるユーザは、彼らが選択した情報をＳＱＬクエリー内へ「注入」する可能性があるからである。

[0039]以下は、口座残高アプリケーションの例としてのＪａｖａコードである。
********************************************************************
import java.sql.*;
importjavax.servlet.http.*;
class AccountViewextends HttpServlet {
privateConnection connection;

public voiddoPost(HttpServletRequest request,
HttpservletResponse response) {
String acctNumber = request.getParameter(“acct”);
CallableStatement stmt = null ;
try {
stmt =
connection.prepareCall(“begin ACCT.get_balance(?, ?); end;”);

// Bind parameter types
stmt.setString(1, acctNumber); // Bind 1st parameter
stmt.registerOutParameter(2, Types.INTEGER); // 2nd is result

// Execute the callable statement
stmt.execute();
int balance = stmt.getInt(2); // get result

response.getWriter().write(“Account balance: “ + balance);
} catch(SQLException ex) { // Trap SQL Errors
response.getWriter().write(“Error: “ + ex.toString() );
} finally {
try {
if (stmt != null) {
stmt.close(); // close the statement
}
} catch (SQLException ex) {
}
}
}
}

********************************************************************

[0040]同じ例に頼って、以下は、口座残高アプリケーションのＰＬ／ＳＱＬコードである。
********************************************************************
CREATE OR REPLACEPACKAGE ACCOUNT IS

TYPE CURSORTYPE IS REF CURSOR;

FUNCTION get_balance(
NAME VARCHAR2
)
RETURN CURSORTYPE;

END;
/

-- Package bodyTEST
CREATE OR REPLACEPACKAGE BODY TEST IS

FUNCTION get_balance(
NAME VARCHAR2
) RETURN CURSORTYPE IS
CURSORRET CURSORTYPE;
N1 VARCHAR2;
BEGIN
N1:= NAME;
OPEN CURSORRET FOR
SELECT balance
FROM ACCOUNTS
WHERE (ACT_NUMBER = N1);
RETURN CURSORRET;
END;
END;
/
commit;
show errors;

exit;

********************************************************************

[0041]上述したように、セキュリティー開発モジュールによって実行される初期オペレーションは、すべての階層のアプリケーションのすべてのソースファイルまたは実行可能なコードファイルをＮｏｒｍａｌｉｚｅｄＳｙｎｔａｘＴｒｅｅ（ＮＳＴ）フォーマットと呼ばれる共通フォーマットに変換することである。

[0042]このステップは、それぞれのソースファイルまたは実行可能なコードファイルをそれが書かれた言語に基づいて構文解析し、そして、構文解析された情報をＮＳＴフォーマットに翻訳することを含む。このステップは、コンパイラがソースファイルまたは実行可能なコードファイルから高級中間言語を生成する最近の高級言語コンパイラ（ＧｎｕＣコンパイラ、ｇｃｃのような）によって実行される第１の段階に極めて類似している。高級言語は、プログラマーに与えられる自由および表現力と、言語を実行可能な形態に効率的に翻訳するためにコンパイラに必要なルールおよび制約とのバランスをとるように設計される。人間は、ＮＳＴフォーマットを書くことはないので、それは、通常プログラマーに提供される素晴らしさおよび手っ取り早さを供給しない。ＮＳＴフォーマットは、いくつかの異なる高級言語から生成されるので、それは、言語間における最大公約数を目標としている。当然ながら、それは、すべての言語におけるすべてのコンストラクトの意味を捕捉するのに十分な表現力を提供しなければならない。コンパイラ研究者は、プログラムモデルを組み立てるためにうまく受け入れられる方法を定義している。例えば、Ａｈｏら，Ｃｏｍｐｉｌｅｒｓ，Ｐｒｉｎｃｉｐｌｅｓ，ＴｅｃｈｎｉｑｕｅｓａｎｄＴｏｏｌｓ，ＰｅａｒｓｏｎＨｉｇｈｅｒＥｄｕｃａｔｉｏｎ（１９８５）の第３章、第４章、および、第８章を参照されたい。

[0043]高級言語からＮＳＴフォーマットへの翻訳は、翻訳される高級言語に特有の一組の翻訳ルールによって管理される。例えば、ＪａｖａからＮＳＴへの変換を制御するいくつかのルールには、以下のようなものがある。

[0044]・ＮＳＴは、Ｊａｖａのｉｍｐｏｒｔ文のようなコンストラクトを含まない。Ｊａｖａのｉｍｐｏｒｔ文は、ＮＳＴにおいて明示的表現を持たない。

[0045]Ｊａｖａは、名前が潜在的に曖昧でない限り、変数名、クラス名、および、メソッド名をプログラマーが完全に修飾することを必要としない。ＮＳＴは、すべての名前が完全に修飾されることを必要とし、そのために、曖昧さを検査する必要がない。名前が、ＪａｖａからＮＳＴへ翻訳されるとき、それは、完全に修飾された形態に翻訳される。Ｊａｖａにおける型およびメソッドの変換は、Ｊａｖａ言語仕様書（第１５．１２節、http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#20448）に説明されるルールおよび命令に従うことによって達成される。

[0046]Ｊａｖａにおいては、すべてのオブジェクトは、ポインタによって参照される。オブジェクトを参照するための方法は１つしか存在しないので、Ｊａｖａにおいては、ポインタ表記は必要としない。ＮＳＴは、オブジェクトが直接にかまたはポインタによって参照されてもよいＣおよびＣ＋＋のような言語を表現するのに使用されるので、すべてのＪａｖａオブジェクト参照は、ＮＳＴにおいては、明示的ポインタ参照表記を含むように翻訳される。

[0047]Ｊａｖａにおいては、ｍｅｍｂｅｒ関数は、キーワード“ｔｈｉｓ”を用いて、それのオブジェクトに作用することができる。ＮＳＴは、“ｔｈｉｓ”キーワードを持たない。その代わりに、ｍｅｍｂｅｒ関数に関連するオブジェクトは、関数への第１の引数として明示的に表現される。

[0048]以下のテキストは、文法型コンストラクトを用いて、ＮＳＴ構文を記述する。以下の約束が、使用される。すなわち、
プロダクション − プレーンワードは、別のプロダクションを参照する。
識別子 − イタリック体のワードは、識別子である。
＜トークン＞ − 括弧によって囲まれたワードまたは文字は、トークンである。
＜ｔｏｋｅｎ＿ｃｌａｓｓ＞ − 括弧によって囲まれたイタリック体のワードは、トークンのクラスを参照する。

CompilationUnit:
(ClassDecl|VarDecl|FunDecl|)*

ClassDecl :
<modifier>*name(ExtendsList)? (ImplementsList)? <{>
(FieldDecl)*
(FunDecl)*
<}>

ExtendsList :
<extends>(Type)+

ImplementsList:
<implements>(Type)+

FieldDecl :
<modifier>*Type name <;>

FunDecl :
<modifier>*Type name <(> (( VarDecl ( <,> VarDecl )* (<,><…>)?)|<…>?<)> <:>
unique_name(Block|<;> )

VarDecl :
Type name<;>

Type :
(
<modifier>*(<primitive_type>|typename)<*>*(<[>numeric_literal?<]>)*
|<modifier>*(<primitive_type>|typename)<*>*(<[>numeric_literal?<]>)*<(> (
VarDecl(<,>VarDecl )*)? <)>
)

Statement :
(label<:>)?
(AssignmentStmt|IfElseStmt|WhileStmt|Gotostmt|DeclStmt|ReturnStmt|CallStmt|Block)
<;>

Block :
<{>
(Statement)*
<}>

AssignmentStmt:
(Location)<=> Expression

DeclStmt :
VarDecl

IfElse :
<if> <(>Expression <)> Block
(<else>Block)?

WhileStmt :
<while><(> Expression <)> Block

ReturnStmt :
<return>Expression

CallStmt :
FunCall

Expression :
(Location|FunCall|Allocation|OpExp|TypeCastExp|LiteralExp)
|<(>Expression <)>

Location :
(
(VarAccess|FieldAccess)(Index)*
|FunIdentifier
)
FunCall :
(
<->>unique_name
|<-->> Expression
この場合、式は、関数ポインタを評価することが要求される。
)
<(>Arg(<,> Arg)* <)>

GotoStmt :
<goto> label

Arg :
(Expression)

Allocation :
<new> Type(Index)*

VarAccess :
name

FieldAccess :
(<[> Type<]>)? (Expression) <.> name
注意：ここで、Ｔｙｐｅは、アクセスされるフィールドの取り囲み型を表現する。
FunIdentifier :
<->> unique_name

Index :
<[>(Location|LiteralExp) <]>

OpExp :
((<unary_op>Expression)|(Expression <bin_op> Expression))

TypeCastExp :
<<>Type<>> Expression

Literlexp :
<literal>

Directive :（ｄｉｒｅｃｔｉｖｅは、単独でどのラインに現れてもよい）
<#> (<source-type>|<source-file>|<source-line> )

a. Terminals
modifier :
:public:
:private:
:protected:
:static:
:final:
:strictfp:
:abstract:
:transient:
:volatile:
:vitulal:
:inline:
:extern:
:const:

primitive_type :
:int:
:long:
:float:
:double:
:boolean:
:short:
:byte:
:char:
:void:
:short char:
:unsigned char:
:unsigned short:
:unsigned int:
:unsigned long:
:long long:
:unsigned long long:
:long double:

[0049]ＮＳＴは、解析のためにプログラムを表現するように設計される。それは、コンパイルされるように、あるいは、人が読むことのできる使いやすい形態を有するようには設計されない。そのようなものとして、それは、それが表現する言語（例えば、Ｃ、Ｃ＋＋、Ｊａｖａ）の多くの使いやすい特徴をサポートしない。単一文宣言および初期化、式における代入、ｓｈｏｒｔ−ｃｉｒｃｕｉｔ演算子、ｔｙｐｅｄｅｆなどのような特徴は、ＮＳＴの要素ではない。むしろ、フロントエンドトランスレータが、ソースまたは実行可能な言語からＮＳＴに変換中に、これらの複雑な表現をより簡単な文からなる等価なシーケンスに変換する責任を有する。次の表は、例としての高級言語コンストラクトとＮＳＴ形態によるそれらの等価な翻訳とを一覧表にしたものである。これらの翻訳の多くは、一時的な変数をＮＳＴに導入する必要があることに注意されたい。

[0050]ＮＳＴにおける型、変数、フィールド、および、関数を変換するために、次のルールが使用され、それらの対応する宣言に戻る。
********************************************************************
VarDecl resolveVar(VarAccess v)
Scope s = v.getScope()
while(s.getVarDecl(v.name) =null)
s =s.getParentScope()
return s.getDecl(v.name)

FieldDecl resolveField(FieldAccess f)
returnresolveType(f.type).getFieldDecl(f.fieldName)

FunDecl resolveFun(FunCall f)
if(f.type != null)
returnresolveType(f.type).getFunDecl(f.funSig)
else
retuenf.getScope() .getRootScope().getFunDecl(f.funSig)

TypeDecl resolveType(Type t)
returnglobalScope.getTypeDecl(f.typeName)

********************************************************************

[0051]上述した高級言語コンストラクトＮＳＴ訳語およびルールを用いて、口座残高例のための例としてのＪａｖａコードが、次の例としてのＮＳＴリストに変換される。ライン番号が使用されるので、以下の説明において個々のラインを参照することができる。
********************************************************************
1 #source-file/home/sean/scratch/patent/AccountView.java
2 #source-type java
3 :class: AccountView :extends:javax.servlet.http.HttpServlet {
4 :private: java.sql.Connection * connection ;
5 :public: void doPost ( AccountView * this- ,
javax.servlet.http.HttpServletRequest *request ,
javax.servlet.http.HttpServletResponse *response ) :
AccountView_doPost_LAccountViewLjavax_servlet_http_HttpServletRequestLjavax_selvlet_http_HttpServletResponse{
6 java.lang.String * acctNumber ;
7 acctNumber =
8 ->
javax_servlet_ServletRequest__getParameter_Ljavax_servlet_ServletRequestLjava_lang_String( request , “acct” ) ;
9 java.sql.CallableStatement * stmt ;
10 stmt = :null: ;
11 {
12 stmt = ->
java_sql_Connection__prepareCall_Ljava_sql_ConnectionLjava_lang_String( [ AccountView ] ( this- ) . connection , “begin ACCT.
13 get_balance (?, ?) ; end;" ) ;
14java_sql_PreparedStatement__setString__Ljava_sql_PreparedStatementILj ava_lang_String( stmt , 1 , acctNumber ) ;
15java_sql_CallableStatement__registerOutParameter_Ljava_sql_CallableS tatementII( stmt , 2 , [ java.sql.Types ] INTEGER ) ;
16java_sql_PreparedStatement_execute_Ljava_sql_PreparedStatement ( stmt ) ;
17 int balance ;
18 balance = ->java_sql_CallableStatement__getInt_Ljava_sql_CallableStatementI ( Stmt , 2 ) ;
19java_io_PrintWriter__write_Ljava_io_PrintWriterLjava_lang_String ( - >javax_servlet_ServletResponse__getWriter_Ljavax_servlet_ServletRespo nse (response ) , ( "Account balance: " + balance ) ) ;
20 }
21 return ;
22 }
23 :-public : void init^ ( AccountView *this- ) : AccountView init^_LAccountView {
24 javax_servlet_http_HttpServlet__init ^_Ljavax_servlet_http_HttpServlet ( this- ) ; 25 return ;
26 }
27 :public : static void clinit^ ( ) :AccountView__clinit^_S_ {
28 return ;
29 }
30 }

********************************************************************

[0052]同様に、同じ高級言語コンストラクトＮＳＴ訳語およびルールを用いて、口座残高アプリケーションのためのＰＬ／ＳＱＬコードの例としての表現が、次の例としてのＮＳＴ表現に変換される。
********************************************************************
31 #source-file/home/sean/scratch/patent/account.sql
32 #source-type java
33 static CURSORTYPE * TEST.get_balance (:sql:varchar2 : NAME ) TEST.get_balance
34 {
35 CURSORTYPE * CURSORRET ;
36 :sql:varchar2 : Nl ;
37 Nl = NAME ;
38 SELECT ( ( ACT_NUMBER == Nl ) ) ;
39 return ;
40 }
41 :sql:varchar2 : ACT_NUMBER ;

********************************************************************

[0053]ここで、この例に関連するＪａｖａからＮＳＴへの変換の一部が、説明される。口座残高アプリケーション例の第４ラインに存在するＪａｖａ文“ｐｒｉｖａｔｅＣｏｎｎｅｃｔｉｏｎｃｏｎｎｅｃｔｉｏｎ”の場合、変換は、ＮＳＴ訳語文“：ｐｒｉｖａｔｅ：ｊａｖａ．ｓｑｌ．Ｃｏｎｎｅｃｔｉｏｎ＊ｃｏｎｎｅｃｔｉｏｎ”をもたらし、それは、上記の第４ラインに存在する。この翻訳を達成するために、３つのルールが、適用される。第１に、Ｊａｖａキーワード“ｐｒｉｖａｔｅ”は、ＮＳＴキーワード“：ｐｒｉｖａｔｅ：”に翻訳されている。第２に、型識別子“Ｃｏｎｎｅｃｔｉｏｎ”は、完全に変換され、“ｊａｖａ．ｓｑｌ．Ｃｏｎｎｅｃｔｉｏｎ”となっている。Ｊａｖａにおいては、この宣言は、変数がオブジェクトの参照であることを指定するための表記を必要としない。なぜなら、プリミティブ型でないＪａｖａにおけるすべての変数は、オブジェクトの参照であるからである。適用される第３のルールは、本発明の一実施形態において、ＮＳＴが、参照を明示的なものにすることを必要とすることに関し、そのために、“＊”が、型識別子の後に付加される。

[0054]別の変換例は、Ｊａｖａ文“ｉｎｔｂａｌａｎｃｅ＝ｓｔｍｔ．ｇｅｔＩｎｔ（２）；／／ｇｅｔｒｅｓｕｌｔ”からＮＳＴ文“ｂａｌａｎｃｅ＝−＞ｊａｖａ＿ｓｑｌ＿ＣａｌｌａｂｌｅＳｔａｔｅｍｅｎｔ＿ｇｅｔＩｎｔ＿Ｌｊａｖａ＿ｓｑｌ＿ＣａｌｌａｂｌｅＳｔａｔｅｍｅｎｔＩ（ｓｔｍｔ，２）”への変換である。最初に、ラインの最後に存在するコメントが、廃棄されていることに注意されたい。Ｊａｖａ関数コールは、コールの最初に“−＞”を付加することによって、ＮＳＴコール表記に翻訳されている。関数名は、完全に変換されており、そのために、“ｇｅｔＩｎｔ”は、“ｊａｖａ＿ｓｑｌ＿ＣａｌｌａｂｌｅＳｔａｔｅｍｅｎｔ＿ｇｅｔＩｎｔ＿Ｌｊａｖａ＿ｓｑｌ＿ＣａｌｌａｂｌｅＳｔａｔｅｍｅｎｔＩ”となる。Ｊａｖａのオブジェクト表記は、ＮＳＴの明示的な引数表記に翻訳されている。オブジェクト名“ｓｔｍｔ”は、関数に渡される第１の引数となるように移動させられている。

[0055]別の例は、口座残高アプリケーションのための例としてのＰＬ／ＳＱＬコードの最後の“ＥＮＤ”文に関連する。この文は、“ｒｅｔｕｒｎ；”命令に変換される。ＮＳＴフォーマットは、フローを制御するためのすべての変更は、明示的になされることを必要とするので、関数中の制御フローパスの終了点は、いかなる場合にも、ｒｅｔｕｒｎ文で終結しなければならない。

[0056]この時点において、すべてのソースファイルまたは実行可能なファイルは、対応するＮＳＴ表現を有することになるので、セキュリティー開発モジュールは、すべてのＮＳＴファイルを読み込むことによって、アプリケーションの均質なモデルを生成することができる。この時点におけるシステムモデルの生成は、共通フォーマットであるので、容易なことである。したがって、既知のシステムモデル化技術が、使用されてもよい。例えば、システムコールグラフが、関数コールサイトを、呼び出された関数の定義に調和させることによって、生成される。ソースまたは実行可能な言語またはフォーマットのルールに基づいてコールグラフノードをともにリンクすることに加えて、フレームワーク規定の知識、ランタイム呼び出し機構、アプリケーションプロトコル、リモートプロシージャコール、および、プロシージャ間プログラム対話のためのその他の機構が、言語とプロセス空間との間隙に橋をかけるシステムのモデルを生成するのに使用される。場合によっては、これは、プログラムソースまたは実行可能なコードの解析だけでなくランタイム環境設定の解析を必要とする。様々な規格本体が、これらのフレームワーク、インタフェース、規定、および、プロトコルを管理する。例として、次のものは、Ｊａｖａにとって重要である。すなわち、
− ＥＪＢ（http://java.sun.com/products/ejb/docs.htmlを参照）。
− ＪＤＢＣ（http://java.sun.com/products/jdbc/reference/index.htmlを参照）。
− ＪａｖａＲｅｆｌｅｃｔｉｏｎ（java.lang.reflect APIdocumentation:http://java.sun.com/j2se/1.4.2/docs/api/java/lang/relect/package-summary.htmlを参照）。
− ＲＭＩ（java.rmi APIdocumentation:http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/package-summary.htmlを参照）。

[0057]そして、最初に、外部から入力がなされたプログラムロケーションを識別することによって、データフロー解析が、実行される。この場合、ユーザ入力は、１つのプログラムロケーション、すなわち、ＳｔｒｉｎｇａｃｃｔＮｕｍｂｅｒ＝ｒｅｑｕｅｓｔ．ｇｅｔＰａｒａｍｅｔｅｒ（“ａｃｃｔ”）文に到着するだけである。一組の入力エントリーポイントから開始して、入力は、代入、関数コール、および、プログラムによって実行されるオペレーションを介してトレースされる。このプロセスは、「汚染伝播」と呼ばれることもある。図２Ａは、この例における汚染伝播パスを示す。図２Ａにおいて、下線付きの数は、上に示されるＮＳＴコードのライン番号に対応する。番号付きの矢印は、ＮＳＴコードにおいて次々に発生する汚染伝播を示す。この例においては、データフロー解析器は、ライン８にあるjavax_servlet_ServletRequest_getParameter_Ljavax_servlet_ServletRequestLjava_lang_Stringをコールすることによって入力がプログラムに到着したこと、および、関数の戻り値が入力値を含むことを決定するために、セキュアーコーディングルールのそれのライブラリーを使用する。したがって、それは、潜在的に汚染されているものとしてコールの戻り値を取り扱う。次に、それは、ライン７にある変数代入を判断し、そして、ＮＳＴフォーマットのセマンティクスは、ＣおよびＪａｖａのような多くの標準的なプログラミング言語の場合と同じものであるので、データフロー解析器は、矢印＃１によって示されるように、汚染をライン７にある代入文の左側に伝播する。変数ａｃｃｔＮｕｍｂｅｒは、この時点において、汚染される。次に、データフロー解析器は、汚染された変数ａｃｃｔＮｕｍｂｅｒが代入の後に使用されるプログラムのロケーションに汚染を伝播する。この例においては、矢印＃２によって示されるように、ａｃｃｔＮｕｍｂｅｒは、ライン７における代入の後に、１つの場所でしか使用されない。その他のセキュアーコーディングルールによって、データフロー解析器は、矢印＃３によって示されるように、汚染を第３の関数引数（ａｃｃｔＮａｍｅ）からライン１４にある第１の関数引数（ｓｔｍｔ）に伝播する。ここで、データフロー解析器は、ａｃｃｔＮａｍｅからｓｔｍｔへの汚染の後に、変数ｓｔｍｔのすべての使用を判断する。ｓｔｍａｔのそのような１つの使用は、ライン１６において発生し、そこでは、ｅｘｅｃｕｔｅメソッドが、コールされ、ｓｔｍｔが、引数として渡される。システムモデルは、データベースとアプリケーションコードとの関係を考慮するので、コールグラフは、ｅｘｅｃｕｔｅコールからｇｅｔ＿ｂａｌａｎｃｅ関数へのリンクを含む。これによって、データフロー解析器は、矢印＃４によって示されるように、実行するためのコールからｇｅｔ＿ｂａｌａｎｃｅ関数の第１のかつ唯一の引数ＮＡＭＥに汚染を伝播する。代入に関する知識を再び適用するとき、データフロー解析器は、ＮＡＭＥは、汚染されており、汚染をライン３７における代入の左側に伝播し、Ｎ１は、矢印＃５によって示されるように、汚染されるという事実を使用する。そして、データフロー解析器は、代入の後のすべてのＮ１の使用を判断する。Ｎ１は、ライン３８におけるＳＥＬＥＣＴ関数に渡される引数の一部であるので、また、データフロー解析器は、汚染された値がＳＥＬＥＣＴ関数への引数として現れることはセキュリティー侵犯であると断定するセキュアーコーディングルールを備えているので、データフロー解析器は、この時点において、潜在的なセキュリティー侵犯をレポートする。

[0058]ユーザ入力が、危険であると指定されている関数に伝播される可能性があるならば、脆弱性が、検出されたことになり、静的解析エンジンは、その脆弱性をユーザにレポートする。静的解析エンジン１２４は、脆弱性を識別するために、１つかまたはそれ以上のセキュリティー開発ルール１２３に頼ることに注意されたい。この例においては、ＳＱＬｓｅｌｅｃｔ関数は、セキュリティー開発ルールによって危険であると指定されるので、静的解析エンジンは、それが、ユーザ入力がＰＬ／ＳＱＬ関数として定義されたＳＱＬｓｅｌｅｃｔ呼び出しに到達する可能性があることを決定すると、脆弱性をレポートする。より詳細には、この例においては、出力は、少なくとも以下の情報を含む。
・脆弱性の検出：ＳＱＬインジェクション、
・エントリーポイント：ＡｃｃｏｕｎｔＶｉｅｗ．ｄｏＰｏｓｔ：ｒｅｑｕｅｓｔ．ｇｅｔＰａｒａｍｅｔｅｒ、
・流れ込み先：ＡｃｃｏｕｎｔＶｉｅｗ．ｄｏＰｏｓｔ：ｓｔｍｔ．ｅｘｅｃｕｔｅ、
・流れ込み先：ＡＣＣＯＵＮＴ．ｇｅｔ＿ｂａｌａｎｃｅ、
・流れ込み先：ＡＣＣＯＵＮＴ．ｇｅｔ＿ｂａｌａｎｃｅ：ＳＥＬＥＣＴ。

[0059]出力は、また、検出された脆弱性のクラス、どのようにして問題を解決することができるかに関する提案、および、さらなる読み込みに関する参照の詳細な説明を含む。セキュリティー開発モジュールは、プロシージャ間で動作してもよい。すなわち、それは、関数コールから関数の実施までユーザ入力をトレースすることもできる。すべての関数は、共通ＮＳＴフォーマットで表現されるので、これは、セキュリティー開発モジュールの静的解析エンジンは言語間およびアプリケーション階層間で動作していることを意味する。

[0060]セキュリティー開発モジュールは、ソースまたは実行可能なコードにおける特定のセキュリティー関連脆弱性を検出するのを助けることに注意されたい。より詳細には、それは、プラットフォーム間および異なるコンピュータ言語間においてこの機能を達成する。したがって、本発明は、グローバルな意味解析を提供する。本発明は、上述した例によって示されるように、エンドツーエンドソリューションを提供し、それは、ウェブ形式からデータベースにわたるものである。

[0061]本発明は、Ｃ−バッファーオーバーフロー、Ｃ／Ｊａｖａの汚染された入力、Ｃ／Ｊａｖａの動的ＳＱＬ、および、順序問題を含む様々な脆弱性を識別する。好ましくは、セキュリティー開発ルールは、危険なデータ変換をトレースするためのルール、データ処理エンドポイント解析を実行するためのルール、および、潜在的なデータ処理エンドポイントを精査するためのルールを含む。好ましくは、セキュリティー開発モジュールは、スタックバッファーオーバーフロー、ヒープバッファーオーバーフロー、フォーマットストリング攻撃、ＳＱＬインジェクション、および、公共ライブラリおよび第三者ソフトウェアにおいて既知である問題のような、汚染伝播問題を識別するように構成される。さらに、セキュリティー開発モジュールは、順序問題（例えば、競合状態、適切なアクセス制御／認証）、疑わしいコード、共通暗号プロトコルの悪用、非暗号乱数発生器、および、悪い種の使用のような、順序制約問題を識別するように構成される。好ましくは、セキュリティー開発モジュールは、また、アーキテクチャー解析のための複雑さ計量および意味論的パターンマッチングをサポートする。本発明の実施形態は、次の言語の処理をサポートする。すなわち、Ｃ、Ｃ＋＋、Ｊａｖａ、および、ＪＡＲ／クラス（バイトコード解析）、ＪＳＰのようなＪａｖａフレームワーク、Ｊ２ＥＥ／ＥＪＢ、Ｓｔｒｕｔｓ、および、Ｔａｐｅｓｔｒｙを含む。本発明の実施形態は、また、ＰＨＰ、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＤＬＬ、Ｕｎｉｘライブラリ、オブジェクトコード、および、アセンブリコードをサポートする。セキュリティー開発モジュールからの出力は、一般的なＸＭＬフォーマットであってもよい。

[0062]上述した例は、静的データフロー解析技術に関する。当業者は、その他の静的解析技術が本発明において使用されてもよいことがわかるはずである。例えば、字句解析技術が、使用されてもよい。字句解析技術は、プログラムを備えるトークンだけを考察することを含む。本発明において使用されてもよい字句解析技術の例は、トークンストリーム内における関数の名前を認識することによって、プログラムが危険なまたは廃止予定の関数を呼び出したロケーションを識別することである。また、意味解析技術が、使用されてもよい。意味解析技術は、プログラミング言語のセマンティクスを理解することに基づくものである。本発明において使用されてもよい意味解析技術の例は、オブジェクトの型、オブジェクトのための継承階層、および、オブジェクトの継承階層内における危険なまたは廃止予定のメソッドを理解することによって、プログラムが、危険なまたは廃止予定の関数から得られるｏｂｊｅｃｔｍｅｍｂｅｒ関数を呼び出したロケーションを識別することである。さらに、プログラム制御フロー解析が、本発明とともに使用されてもよい。プログラム制御フロー解析は、実行される可能性があるアプリケーションにおける潜在的な制御フローパスを評価すること、および、セキュリティー脆弱性を表現する可能性があるパスを探索することを含む。制御フロー解析によって識別される可能性がある脆弱性の１つの例は、ＴＯＣＴＯＵ（検査時が使用時）脆弱性と呼ばれる。プログラムが、制御フローパスを含み、その制御フローパスにおいて、そのプログラムが、ファイルのパーミッションを検査し、その後に、同じ制御フローパス上で、ファイルが変更されていないことをなんらかの方法で確認することなくそのファイルをオープンしたならば、そのプログラムは、ＴＯＣＴＯＵ脆弱性を含む。ＴＯＣＴＯＵ脆弱性を識別するための制御フロー解析技術は、最初に、ファイルパーミッション検査が実行されたプログラムロケーションを識別し、そして、この技術は、その同じファイルがその後にオープンされたかどうかを決定するために、それらのロケーションから前方へすべての潜在的な制御フローパスを辿る。

[0063]セキュリティー開発モジュール１１４について十分に説明したので、ここで、セキュリティーテストモジュール１１６に注目する。セキュリティーテストモジュール１１６は、脆弱性に関してアプリケーションを動的にテストし、既知の弱点の存在を確認し、そして、既存のツール内において動作するテストケースを自動的に生成するための実行可能なコードを含む。上述したように、セキュリティーテストモジュール１１６は、攻撃マネージャーモジュール１２８、攻撃データベース１３０、セキュリティーテストルール１３１、障害注入モジュール１３２、および、テストレポート生成器１３４によって実施されてもよい。

[0064]図３は、セキュリティーテストモジュール１１６の実施形態に関連する処理オペレーションを示す。初期オペレーションは、ソースまたは実行可能なコード３００内の潜在的なセキュリティー脆弱性を識別することである。攻撃マネージャーモジュール１２８が、このオペレーションを実行するのに使用されてもよい。より詳細には、攻撃マネージャーモジュールは、攻撃計画を生成および管理し、攻撃を提案する解析モジュールを選択し、そして、攻撃を市販のテスト商品にエクスポートする能力をユーザに提供する。図３に示されるように、セキュリティー開発モジュール入力３０２、および、攻撃データベース１３０およびセキュリティーテストルール１３１からの情報３０３が、潜在的な脆弱性を識別するのに使用される。攻撃データベース１３０は、既知のエクスプロイトおよびユーザ定義エクスプロイトを含む、好ましくは、攻撃データベースは、リモートコンピュータから定期的に更新される。さらに、攻撃データベース１３０は、好ましくは、テスト中のアプリケーションに対する特定の攻撃によってカスタマイズされる。セキュリティーテストルール１３１は、標準的な攻撃ルールおよび特定のアプリケーションのためにカスタマイズされたユーザ定義攻撃ルールを含む。セキュリティーテストルール１３１は、また、リモートコンピュータから定期的に更新されてもよい。

[0065]攻撃マネージャーモジュール１２８によって識別される潜在的な脆弱性は、脆弱性テストをソフトウェアに施すために（図３のオペレーション３０６）、障害注入モジュール１３２によって処理される。障害注入モジュール１３２は、既知の攻撃およびカスタマイズされた攻撃に対するコードの脆弱な部分を体系的にテストするための障害注入実行可能コードを含む。例えば、障害注入モジュール１３２は、入力フィールド、クッキー、ヘッダーなどにエクスプロイトを適用する。そして、これらの環境下におけるコードの動作が、解析される（図３のオペレーション３０８）。障害注入モジュール１３２が、この解析を実行するのに使用されてもよい。最後に、結果が、ユーザにレポートされる（オペレーション３１０）。テストレポート生成器１３４の実行可能なコードが、このレポートする機能に使用されてもよい。また、結果は、さらなる脆弱性を識別するために、攻撃マネージャー１２８に配信されてもよい（図３のオペレーション３００）。また、結果を報告するオペレーション３１０は、テストアプリケーションによって実行されるべきスクリプトとして動作結果をレポートすることを含んでもよい。

[0066]ここで、本発明のセキュリティー監視モジュール１１８に注目する。セキュリティー監視モジュール１１８は、監視されるソースまたは実行可能なコードの選択された位置にセンサーを挿入するためのセンサー挿入モジュール１３６を含む。また、セキュリティー監視モジュール１１８は、詐欺行為およびその他の異常行為を検出しそしてそれに対応するために、センサーからのデータを解析するための監視解析モジュール１３８の形で実行可能コードを含む。監視解析モジュール１３８は、一組のセキュリティー監視ルール１３７を呼び出す。セキュリティー監視ルール１３７は、標準的なセキュリティールールおよびユーザ定義セキュリティールールを含んでもよい。好ましくは、セキュリティー監視モジュールは、また、監視レポート生成器１４０を含む。

[0067]図４は、セキュリティー監視モジュール１１８の実施形態に関連する処理オペレーションを示す。センサーが、ソースまたは実行可能コード内に挿入される（４００）。センサー挿入モジュール１３６が、このオペレーションを実行するのに使用されてもよい。図４に示されるように、セキュリティー開発モジュール入力４０２およびセキュリティーテストモジュール入力４０４が、コード内におけるセンサー位置を決定するのに使用されてもよい。それぞれのセンサーは、元々のソースまたは実行可能コードに関連する選択された動作基準を識別およびレポートするための実行可能コードである。

[0068]そして、コードは、センサー４０６とともに実行される。センサーは、セキュリティーイベントのストリームを生成する。そして、コードの動作は、セキュリティーの観点から監視される（４０８）。より詳細には、センサーからのセキュリティーイベントのストリームは、詐欺行為および悪用を検出するために、処理される。監視解析モジュール１３８およびセキュリティー監視ルール１３７が、このオペレーションを実行するのに使用されてもよい。そして、結果は、監視レポート生成器１４０を用いてレポートされてもよい。その代わりに、あるいは、それに加えて、結果は、センサー挿入プロセスを洗練するために、または、アプリケーションのビヘイビアを修正するために、センサー挿入モジュール１３６にフィードバックされてもよい（図４のオペレーション４００）。

[0069]図５は、セキュリティー監視モジュール１１８のオペレーションを示す。より詳細には、図５は、センサー５００とともにコードを実行することのブロック図を示す。実行されるコード内に存在するセンサーは、セキュリティーイベント５０２を生成し、そのセキュリティーイベント５０２は、監視解析モジュール１３８に適用される。監視解析モジュール１３８は、対策コマンド５０４を生成する。監視解析モジュール１３８のこの実施形態においては、ローカル監視解析モジュール５０６は、セキュリティーイベント５０２を処理するために、ローカル監視処理ルール５０８に頼る。ローカル監視処理ルール５０８は、実行しているアプリケーションに適したビヘイビアを管理する一組の実行可能なルールを定義する。また、グローバル監視処理ルール５１２に頼るグローバル監視解析モジュール５１０が、使用されてもよい。グローバル監視処理ルールは、一組の実行しているアプリケーションに適したビヘイビアを管理する一組の実行可能なルールを定義する。したがって、例えば、関連するプログラムまたはオペレーションにおいて識別されたセキュリティー脆弱性が、識別され、この情報が、ローカルプログラムの実行中に類似する問題が発生しているかどうかを評価するのに使用される。したがって、セキュリティー監視モジュール１１８は、大きな組のビヘイビアおよび環境に頼るように実施されてもよい。警報５１４が、ローカル監視解析モジュール５０６とグローバル監視解析モジュール５１０との間で交換されてもよい。さらに、クエリーおよび応答５１６が、これらのモジュールの間で交換されてもよい。

[0070]センサー挿入モジュール１３６は、様々な基準を考慮する。例えば、センサー挿入モジュールは、アプリケーションが受ける可能性のある攻撃の種類をソースまたは実行可能コードおよび使用されるライブラリに基づいて決定するための実行可能コードを有する。階層間解析が、防御されるべき特定の関数、モジュール、または、プログラム領域を識別するのに使用されてもよい。例えば、パスワードが、ＨＴＭＬ／ＪＳＰから環境設定を介してＪａｖａで記述されたログインコードまでトレースされてもよい。また、データフロー解析が、プログラム内においてユーザ入力が現れる可能性のある場所をトレースするのに使用されてもよい。センサーは、好ましくは、ユーザ入力が信頼できるデータとなる箇所に付加される。制御フロー解析が、実行することのできないパスをインストルメントするのを回避するのに使用されてもよい。また、ユーザ入力が、インストルメンテーションプロセスを案内するのに使用されてもよい。例えば、ユーザは、範囲内に存在する変数のリストを提供してもよく、ユーザは、ユーザがセンサーを生成したとき、型を検査してもよく、あるいは、ユーザは、プログラムの特定の態様に関連する可能性があるメソッドのリストを提供してもよい。

[0071]セキュリティー監視モジュール１１８は、コードをインストルメントするための最良の箇所および実行されるべき最も適切な種類の解析を決定するために、環境設定ファイル、統計的解析、および、セキュリティー開発モジュール１１４およびセキュリティーテストモジュール１１６からの情報を含む多種多様なソフトウェアセキュリティー関連情報に関する情報を収集およびレポートする。セキュリティー監視モジュール１１８は、多くのレベルで様々な検出機構を使用する。一実施形態においては、セキュリティー監視モジュール１１８は、署名、パターンマッチング、および、統計的解析を使用する。

[0072]アプリケーションが配置される前にセキュリティー脆弱性をすべて除去できるとは限らないので、セキュリティー監視モジュール１１８が、使用される。一個のソフトウェアが長い間にどのような形で悪用されあるいは詐欺的に使用される可能性があるかをすべて予見することは特に難しいことである。さらに、悪用を検出しかつそれに対応するのに必要なコードは、多くの場合、複雑であり、かつ、アプリケーションの機能とはほとんど無関係である。さらに悪いことには、最近のアプリケーションは、一般的には、多数のコンピュータ間で実行される異質のコンポーネントからなる。

[0073]セキュリティー監視モジュール１１８は、既存のプログラムの上に動的なセキュリティービヘイビアを積み重ねることによって動作する。この技術は、攻撃および悪用の両方にリアルタイムに対応する機構を提供する。このアプローチは、アスペクト指向プログラミング、ランタイムインストルメンテーション、リアルタイムイベント相関、および、アプリケーションベース侵入検出を組み合わせることに基づいたものである。

[0074]一般的な侵入検出システムは、ネットワークトラフィックかまたはアプリケーションが残したログファイルおよびその他のアーチファクトのいずれかに作用する。ネットワークトラフィックが、暗号化されていれば、ネットワークベース侵入検出は、コンテンツを解析することができない。非暗号化データに作用する場合でも、ネットワークパケットまたはログファイルエントリーのコンテンツを解釈するのは、侵入検出システムの義務である。ほとんどの場合、これは、一般的な侵入検出システムが、犯行後に、かつ、アプリケーションの内部構造がわからないまま、イベントを解析させられることを意味する。結果は、損害を加えられて初めて、実際の攻撃に関する多くの正しくない警報および通知となる。なによりも悪いことには、アプリケーションの内部がわからないことは、検出される可能性がある攻撃または悪用の種類を大きく制限する。

[0075]セキュリティー監視モジュール１１８は、防御ビヘイビアを付加するためのフレームワークをランタイム時にアプリケーションに提供することによって、これらの制限を克服する。セキュリティー開発者は、プログラムが実行されているときに、内部プログラム変数の値、実行パス、および、動作特性を調査することができる。セキュリティー関連イベントは、バンドの外側で、あるいは、セキュリティー要件および動作要件によって決定されるようなプログラム制御フローに沿って、解析することができる。複数のマシンからのイベントは、システムの状態の大きな概観を提供するために、互いに相関をとることができる。

[0076]セキュリティー監視モジュール１１８は、多くのレベルで様々な検出機構を使用する。このモジュールは、アプリケーションレベルの検出に適した新しい組の機構を使用することに加えて、今日のネットワークおよびホストベース侵入検出システム（ＩＤＳ）において使用される様々な技術、すなわち、署名およびパターンマッチングおよび統計的解析を合成する。既存のＩＤＳとは対照的に、セキュリティー監視モジュール１１８は、悪用に極めて関係している。セキュリティー監視モジュール１１８は、権限を与えられていないユーザを締め出すための手段を使用するが、それの最も強力な特徴の１つは、権限を与えられたユーザによる悪用の検出である。これは、権限を与えられていないユーザによる悪用に対してほとんど無力である既存の技術（例えば、アプリケーションファイアウォールおよびデータベースＩＤＳ）とは対照的なものである。

[0077]セキュリティー監視モジュール１１８による攻撃の検出は、多くの異なるレベルで発生する。攻撃は、単一イベントの簡単な解析から、低いレベルにおいて明白なものもある。ある攻撃は、ステートフル解析を必要とするものもあり、イベントの相関は、時間およびロケーションにおいて本質的に異なり、したがって、検出は、システム資源をかなり必要とする。検出は、攻撃と必ずしも同時に発生するとは限らないので、様々な応答機構を使用しなければならない。セキュリティー監視モジュールは、ある環境においては、即座に応答し、また、別の環境においては、遅れた応答を発生させ、人間のオペレータが応答を発生させかつそれを無効にすることのできる機構を提供する。

[0078]セキュリティー監視モジュール１１８は、それの環境をトレースするように、また、できるだけ自己設定するように、実施される。したがって、例えば、セキュリティー監視モジュール１１８は、コードをインストルメントするための最良の箇所および実行されるべき最適な種類の解析を決定するために、それが得ることのできるものであればどのような情報（例えば、環境設定ファイル、イントロスペクション、統計的解析、セキュリティー開発モジュールおよびセキュリティーテストモジュールからの情報、アーキテクチャーから得ることのできる仮定）でも利用する。文脈的認識とともに、セキュリティー監視モジュール１１８は、好ましくは、柔軟性および拡張性が得られるように構成される。セキュリティー監視モジュールアドミニストレータが、アプリケーションにおける何らかの弱点または重要なネクサスを認識していれば、設定可能な命令が、この問題を解決するために、利用可能である。

[0079]セキュリティー監視モジュール１１８の上述した特徴化は、セキュリティー監視モジュール１１８によって実行される特定のオペレーションのいくつかの例を参照してより完全に理解される。これらの例は、いくつかのさらなる概念を導入することを必要とする。図６は、セキュリティー監視モジュール１１８を実施するのに使用されてもよい実行可能なコードコンポーネントを示す。この図面は、一組のセンサー６００＿Ａ〜６００＿Ｎを示す。これらのセンサーは、イベント６０２＿Ａ〜６０２＿Ｎを生成する。例として、これらのイベントのあるものは、トランシーバ（例えば、トランシーバ６０４＿Ａおよび６０４＿Ｂ）に転送され、また、あるものは、解析モジュール（例えば、６０６）に転送される。トランシーバ６０４は、以下で説明するように、メッセージ、イベント６０２、または、イベント処理ルール（ＥＰＲ）６１４を生成する。解析モジュール６０６は、警報６１６を生成する。トランシーバ６２０＿Ａ〜６２０＿Ｎからなるさらなる階層が、この情報を処理するのに使用される。最終的には、トランシーバは、ディレクターまたはトランシーバ６２２にレポートする。ディレクター６２２は、ＥＰＲ６１４をトランシーバ階層の上から下へ転送する。ＥＰＲ６１４は、また、トランシーバ（例えば、６０４、６２０）、センサー（例えば、６００）、および、解析モジュール（例えば、６０６）を制御するのに使用される。これらのオペレーションは、以下の説明からより完全に理解される。

[0080]メッセージは、トランシーバ間で転送されるデータのための一般的なコンテナである。メッセージは、データおよび／または命令を含む。例えば、メッセージは、イベント処理ルール（ＥＰＲ）をトランシーバ階層の上から下へおよび下から上へ配信する。

[0081]さらなる概念は、イベント６０２の概念である。イベント６０２は、データの基本単位である。イベントは、センサー６００から発生し、時刻、種類（イベントの一般的な種類、すなわち、ログイン、データベースクエリー、データベース更新、など）、ソース（それが生成されたセンサーの名前）、および、コンテクスト（アプリケーションおよびサーバーの名前）によって識別される。イベントは、センサーによって記録された情報（例えば、関数パラメータ、ユーザ、セッション情報、スタックトレース、投げられた例外など）をカプセル化する。警報６１６は、特殊な種類のイベントであり、それは、センサーからのイベントに応じて、解析モジュール６０６によって生成される。

[0082]イベント処理ルール（ＥＰＲ）６１４は、イベントをどのようにハンドルするかに関する指示をトランシーバに提供する。ＥＰＲは、３つの形の中の１つによって、すなわち、スタートアップ環境設定の一部として、管理コンソールを介してアドミニストレータによってランタイム時に動的に、あるいは、何か（通常、侵入の検出または嫌疑による）に応じて動的に、発生させられるが、大きな負荷を加えられている様々なトランシーバにかかる処理負荷を調節するのに使用することができる。本発明の一実施形態においては、ＥＰＲは、以下の能力、すなわち、イベントのコンテンツを調査し、イベントのコンテンツを変更し、イベントを廃棄（フィルタリング）するようにトランシーバに指示し、設定された時間の後に満了し、解析モジュールをインスタンス化およびパラメータ化し、イベントを解析モジュールに送り、解析モジュールからの応答を送り、トランシーバ内に記憶された状態にアクセスし、センサーをイネーブルまたはディスエーブルし、同期して動作するようにセンサーに指示し、ＥＰＲが適用されるべき単一のまたは一組のトランシーバを指定し、および／または、正規表現を評価する能力を有する。

[0083]ＥＰＲは、システムユーザによって書かれてもよく、自動化されたツールによって開発されてもよく、あるいは、イベントに応じて、システムコンポーネントによって合成することができる。ＥＰＲは、典型的には、人間が読むことのできるフォーマットを有し、しかもまた、効率的な解釈をもたらすランタイム表現をサポートする。

[0084]セキュリティー監視モジュール１１８に関連する別の概念は、トランシーバ６０４の概念である。トランシーバ６０４は、階層内に配置され、そして、イベントおよびＥＰＲを送信する責任を有する。センサーは、トランシーバの特殊なクラスであり（それらのセンサーは、イベントを生成する）、ディレクター６２２もまた、トランシーバの特殊なタイプである。トランシーバの階層は、多くのシステム間に、場合によっては、同じシステム上の異なるプロセス間に、そして、単一アプリケーション内の多くのスレッド間に、分散する。トランシーバ階層は、侵入検出が必要とする集中的な作業負荷の分散を助ける。トランシーバは、イベントを、フィルタリングし、相関をとり、そして、処理することができる。

[0085]典型的なトランシーバ階層は、多くのレベルのトランシーバを含む。センサーは、実際のデータを収集し、それをアプリケーションレベルのトランシーバまで転送する。単一マシン上で実行されている複数のアプリケーションが存在するならば、マシンレベルのまたは仮想マシンレベルのトランシーバが存在してもよい。アプリケーションレベルのトランシーバは、メッセージをマシン上のより高いレベルのトランシーバへ送信するのに必要な何らかのＩＰＣに対して責任を有する。最も高いレベルのトランシーバは、メッセージをネットワークを介してディレクターまたは親トランシーバへ送信する責任を有する。処理負荷を下げるために、より迅速なイベント相関を可能にするために、あるいは、ディレクターよりも下におけるフィルタリング能力を増大させるために、さらなるトランシーバレベルが、ディレクターの下に付加されてもよい。

[0086]ＥＰＲは、トランシーバのビヘイビアを指示する。ＥＰＲは、親トランシーバから子へ上から下に転送される。中間トランシーバの場合、ＥＰＲは、フィルタリングを実施するのに使用されてもよく、あるいは、特定の種類の解析をイネーブルまたはディスエーブルするのに使用することができる。センサーの場合、ＥＰＲは、アプリケーションのビヘイビアを動的に変更する方法を提供する（例えば、権限を与えられていないユーザが、ログインすることを試みると、例外を投げる）。

[0087]解析モジュール６０６は、どのトランシーバ６０４にプラグインすることができる。大多数のモジュールは、ディレクターによって実行されるが、階層のより低いレベルに存在するいくつかのより簡単なステートレスモジュールを実行することが望ましいこともある。モジュールは、イベントがトランシーバチェーンを下から上へ転送される前または転送された後に、イベントに基づいて実行され、判断はＥＰＲによって決定することができる。

[0088]センサー６００は、本発明のセキュリティー監視モジュール１１８とともに使用されるさらなるコンポーネントである。センサーは、特殊なクラスのトランシーバである。すなわち、センサーは、イベントを生成する。上述したように、センサーは、ランタイム時にアプリケーション内に組み込まれる。それらは、コード内に埋め込まれるので、それらは、動きが軽くかつフォールトトレラントでなければならない。センサーは、アプリケーションを中断させてはならない。センサーの通常オペレーションは、コンテクストデータがイベントに関連しているものなら何でもパッケージし、それのＥＰＲがイベントとマッチングするかどうかを検査し、そして、イベントをそれの親トランシーバに渡すことである。

[0089]また、セキュリティー監視モジュール１１８は、ディレクター６２２とともに動作する。ディレクターは、最上位のレベルのトランシーバである（すべてのイベントの目的地）。ほとんどの解析モジュールは、ディレクターレベルで実行される。ディレクターは、解析モジュールによってアクセスすることのできる共有状態を記録しかつ維持し、そして、警報をレポートする責任を有する。

[0090]解析モジュールは、到着するイベントに明確な種類の解析を実行する設定可能なユニットである。できるだけ多くの種類の侵入を検出するために、様々な異なる解析モジュールが、デフォルト設定によって使用される。好ましくは、解析モジュールは、カスタマイズされた検出機構を記述するのを助けるために、関連するアプリケーションプログラムインタフェース（ＡＰＩ）を有する。本発明の一実施形態においては、解析モジュールは、ルールベース解析（論理的テスト、しきい値、および、パターンマッチング）および統計的解析を含む。イベントが、解析モジュールをトリガーすると、それは、警報を生成し、その警報をそれが含むトランシーバへ渡す。警報の重大度レベルに依存して、モジュールは、ＥＰＲを生成してもよく、そのＥＰＲは、トランシーバ階層の上から下へ伝播される。

[0091]本発明の一実施形態においては、解析モジュールは、簡単なインタフェースをＥＰＲ６１４へエクスポートする。ＥＰＲは、初期化時に、および、それぞれのイベントが発生したときに、一組の環境設定パラメータを提供する。解析モジュール自体は、極めて簡単なものであってもよく、あるいは、下部において、極めて複雑なものであり得る。あるものは、解析を実行するための一組の予め定められたパラメータを利用し、また、あるものは、それらが使用されるときにアプリケーションに関して適応学習し、および、学習された統計的パターンからはっきりと浮き出てくるイベントに反応する。解析モジュールをより柔軟性のあるものかつ再利用可能なものにするために、１つの解析モジュールは、別の解析モジュールをインスタンス化しかつそれを呼び出すことを許可される（例えば、ユーザ入力の値の妥当な範囲を学習するモジュールは、妥当性を実際に確認する範囲検査モジュールを利用することができる）。例として、解析モジュールは、値のしきい値検査器、イベント頻度のしきい値検査器、セットの比較、正規表現検査器、ステートフルパターンマッチング、統計的モーメント解析、および、マルコフモデル解析（すなわち、状態遷移の確率）を含んでもよい。

[0092]上述した概念に頼って、セキュリティー監視モジュール１１８のオペレーションのいくつかの例を示す。“Ｊｏｅ”は、通常、日中に彼のシステムにログインすると仮定する。ある日、彼が、３：００ＡＭにログインする。この状況において、セキュリティー監視モジュール１１８は、このイベントを記録し、そして、Ｊｏｅによって実行されるすべてのオペレーションに周到な注意を払う。次に、Ｊｏｅは、海外口座へ極めて大きなトランザクションをなすことを試みる。彼は、通常、国内口座間で小さなトランザクションしか行わないので、セキュリティー監視モジュール１１８は、一時的に彼をロックアウトし、アドミニストレータに通知する。

[0093]もう１つの例は、“Ｆｒｅｄ”が１０文字のストリングをパラメータとして備える関数をコールする場合である。これまでには、この関数は、必ず、４文字のストリングを備えてコールされた。この場合、セキュリティー監視モジュール１１８は、トランザクションをブロックしないが、そのことを怪しい行動としてログに記録する。また、セキュリティー監視モジュール１１８は、電子メールをアドミニストレータに送信してもよい。

[0094]さらなる例は、データベーストランザクションが開始される場合である。この場合、すべてのパラメータは、正常に見えるが、スタックトレースが、異常である。したがって、警報が、生成される。さらに別の例は、特定の医者が、いつも、特定のＩＰアドレスからログインする場合である。ある日、彼が、東欧のどこかのＩＰアドレスからログインする。この場合、セキュリティー監視モジュール１１８は、ユーザは旅行中である可能性があると認識し、あるいは、誰かがパスワードを盗んだ可能性があると認識する。その結果として、警報が、生成される。

[0095]この最後の例を考える。ＳａｌｌｙＨａｃｋｅｒは、医療記録サイトにログインし、弱点がないかサイトを探索する。彼女は、ビューレコードページへの要求上においてレコードｉｄ番号を人手で編集する方法を見つけ出し、データベースから任意のレコードをアプリケーションに検索させる。そして、Ｓａｌｌｙは、データベース内のすべてのレコードを検索するために、２行のＰＥＲＬスクリプトを書き込む。より詳細には、Ｓａｌｌｙのスクリプトは、／ｖｉｅｗｒｅｃｏｒｄ．ｊｓｐ？ｉｄ＝１００１を得るためのＨＴＴＰ要求を作成する。サーブレットエンジン内のセンサー（ＳｅｒｖｌｅｔＳｅｎｓｏｒ）は、イベントを生成し、そのイベントは、ディレクターまでトランシーバ階層を下から上に転送される。イベントは、ディレクター内の一連のＥＰＲを通過する。１つのＥＰＲは、頻度しきい値を検出するための解析モジュールにイベントを送る。以下は、このオペレーションを実施するための例としてのコードである。
********************************************************************
<epr name="TooFast">
<host>Director</host>
<module type="RateThreshold" name="rt">
<param name="rate">l</param>

</module>
<clause>
<condition>
<equals field="event. sensor" value="ServletSensor"/>
</condition>
<action>
<analyze module="rt" />
</action>
</clause>
</epr>
********************************************************************

[0096]数秒後に、Ｓａｌｌｙのスクリプトは、第５の要求（／ｖｉｅｗｒｅｃｏｒｄ．ｊｓｐ？ｉｄ＝１００５）を作成し、ＳｅｒｖｌｅｔＳｅｎｓｏｒは、イベントを生成する。ディレクターにおいて、ＴｏｏＦａｓｔが、それの“ｒｔ”モジュールにイベントを送り、そのモジュールは、高速のページ要求によってトリガーされる。解析モジュールは、ＥＰＲを生成し、トランシーバ階層の上から下にそれを送信する。以下のコードが、これらのオペレーションを実施するのに使用されてもよい。
********************************************************************
<epr name="IntrustionResponse.l">
<expires> Wed Nov 27 14:30:15 PDT 2004</expires>
<host>ServletSensor</host>
<clause>
<condition>
<or>
<equals field="event.username" value="sally.hacker"/>
<equals field="event.remoteaddr" value="136.205.62.161"/>
</or>
<condition>
<action>
<exception message=" Account Blocked" />
</action>
</clause>
</epr>

********************************************************************

[0097]ＥＰＲは、ＳｅｒｖｌｅｔＳｅｎｓｏｒに到着し、ＥＰＲのそれのチェーンに付加される。ディレクターに戻ると、解析モジュールは、警報を生成し、その警報は、管理コンソールに送信される。Ｓａｌｌｙのスクリプトは、／ｖｉｅｗｒｅｃｏｒｄ．ｊｓｐ？ｉｄ＝１００５を要求する。ＳｅｒｖｌｅｔＳｅｎｓｏｒにおいて、ＩｎｓｔｒｕｓｔｉｏｎＲｅｓｐｏｎｓｅ１ＥＰＲが、イベントを検出し、例外を投げるようにセンサーに命令し、ページ要求をブロックする。

[0098]すぐに、システムアドミニストレータは、管理コンソールにおいて、高い優先順位の警報に気がつく。アドミニストレータは、Ｓａｌｌｙのスクリプトによってなされた要求を調査し、５つの要求のすべてが、その他の患者の記録を戻したことに気がつく。アドミニストレータは、ここで、システムにおけるこの弱点を迅速にパッチしなければならない。すなわち、ＳａｌｌｙのＩＰアドレスおよびアカウントをブロックすることは、長期間にわたってＳａｌｌｙまたはその他のハッカーを締め出すことはない。アプリケーション開発者およびセキュリティー監視モジュールアドミニストレータを含む小さなチームが、素早く召集される。パッチを開発し、テストし、そして、配置できるまで、彼らは、問題を解決するための一組のＥＰＲを書き込む。１つのＥＰＲ（Ａ）は、ＥＪＢコンテナのＪＤＢＣ要求を監視するセンサーを含むいくつかのセンサーからのイベントを監視する。このＥＰＲは、アプリケーションレベルトランシーバにおいて実行されるので、それは、それが必要とするすべてのセンサーからのイベントにアクセスする。第２のＥＰＲ（Ｂ）は、このトランシーバ内にある解析モジュールを起動し、その解析モジュールは、イベント相関を実行し、単一ユーザトランザクションからの複数のイベントを互いにリンクする。最後に、ＥＰＲ（Ｃ）が、ＥＪＢコンテナのセンサーに書き込まれ、そのＥＰＲ（Ｃ）は、処理する前に、アプリケーショントランシーバからの応答を待つようにそのセンサーに命令する。ビューレコードページへの悪意のある要求は、この時点において、以下のシーケンスを開始する。

[0099]アプリケーションエントリーポイントにおけるセンサーは、ユーザトランザクションの開始を指示するイベントを生成する。アプリケーショントランシーバにおいては、ＥＰＲ（Ｂ）は、このイベントを相関モジュールへ送り、その相関モジュールは、新しいイベント列を発行し始める。

[0100]アプリケーション内にあるセンサーは、要求イベントを生成し、そのイベントは、セッションｉｄ、ユーザアカウント、要求パス、および、その他の様々なパラメータを含む。アプリケーショントランシーバにおいては、このイベントは、第１のイベントと相関がとられる。ＥＪＢコンテナ内にあるセンサーは、ＪＤＢＣ要求によって戻されたレコードに関する情報を有するイベントを生成する。ＥＰＲ（Ｃ）は、続行する前に、アプリケーショントランシーバからの応答を待つようにセンサーに命令する。アプリケーショントランシーバにおいては、イベントは、このトランザクションからのその他のイベントと相関がとられる。そして、ＥＰＲ（Ａ）は、戻されたレコードからのｕｓｅｒｉｄ（イベント１）が実際のｕｓｅｒｉｄ（イベント２）と一致するかどうかを確認する。すべてが、ＯＫであれば、ＥＰＲ（Ａ）は、待っているセンサーに続行するように命令する。ｕｓｅｒｉｄが、一致しなければ、ＥＰＲ（Ａ）は、待っているセンサーに例外を投げるように命令し、警報を生成する。

[0101]本発明の一実施形態においては、セキュリティー監視モジュール１１４は、ユーザのオンラインビヘイビアを監視するセキュリティー監視ルール１３７を含む。与えられたあらゆる場合におけるユーザのオンラインビヘイビアは、ユーザのこれまでのビヘイビア傾向を特徴づけるルールと比較される。これらの２つのビヘイビア間にしきい値を超える差があれば、強化されたセキュリティーが、呼び出される。例えば、ユーザのビヘイビアは、ユーザのブラウザ、ユーザが働いている時間帯、アプリケーションの中でのユーザの流れなどに関して監視されてもよい。与えられた時刻におけるビヘイビアが、これまでのビヘイビア傾向と矛盾していれば、チャレンジ応答シーケンスのようなセキュリティーイベントが、呼び出される。

[0102]当業者は、本発明のセキュリティー監視モジュール１１８に関連する多くの利点がわかるはずである。セキュリティー監視モジュール１１８は、プログラムを書き換えることなく、既存のプログラムの上に動的なセキュリティービヘイビアを積み重ねるのを助ける。この技術は、攻撃および悪用の両方にリアルタイムに応答するための機構を提供する。このアプローチは、アスペクト指向プログラミング、ランタイムインストルメンテーション、リアルタイムイベント相関、および、アプリケーションベース侵入検出を組み合わせることに基づいたものである。本発明は、ソフトウェアプログラムの使用を開発者が意図した機能にのみ限定するために、その実行されているソフトウェアプログラムを防御する方法を提供する。

[0103]本発明の一実施形態は、様々なコンピュータ実施型オペレーションを実行するためのコンピュータコードをそこに有するコンピュータ可読媒体を備えるコンピュータストレージプロダクトに関係する。媒体およびコンピュータコードは、本発明のために特別に設計されコンストラクトされたものであってもよく、あるいは、それらは、コンピュータソフトウェアの当業者が利用できる周知の種類のものであってもよい。コンピュータ可読媒体の例は、限定はしないが、ハードディスク、フロッピーディスク、および、磁気テープのような磁気媒体、ＣＤ−ＲＯＭおよびホログラフィック素子のような光媒体、フロプティカルディスクのような磁気光学媒体、および、特定用途向け集積回路（“ＡＳＩＣ”）、プログラマブルロジックデバイス（“ＰＬＤ”）、および、ＲＯＭデバイスおよびＲＡＭデバイスのようなプログラムコードを記憶および実行するように特別に構成されたハードウェアデバイスを含む。コンピュータコードの例は、コンパイラによって生成されたようなマシンコード、および、インタプリタを用いてコンピュータによって実行されるより高いレベルのコードを含むファイルを含む。例えば、本発明の実施形態は、Ｊａｖａ、Ｃ＋＋、または、その他のオブジェクト指向プログラミング言語および開発ツールを用いて実施されてもよい。本発明の別の実施形態は、マシン実行可能ソフトウェア命令の代わりに、あるいは、マシン実行可能ソフトウェア命令と組み合わせて、ハードワイヤ回路で実施されてもよい。

[0104]説明のためのこれまでの記述は、本発明を十分に理解するために特定の用語を使用したが、当業者には、特定の細部は、本発明を実施するのに必要とされないことは明らかである。したがって、本発明の上述した特定の実施形態は、説明および記述のために提供されたものである。それらは、本発明を完全に網羅すること、あるいは、開示された形態そのものに本発明を限定することを意図するものではない。当然ながら、上述した教示を考慮して、多くの変更および変形が、可能である。それらの実施形態は、本発明の原理および本発明を実際に適用することを最も良く説明するために、選択され、かつ、説明されたものであり、それによって、それらは、その他の当業者が、予想される特定の使用方法に合わせた様々な変更を備える本発明および様々な実施形態を最良の形でうまく利用するのを可能にする。添付の特許請求の範囲に記載される請求項およびそれらに等価なものは、本発明の範囲を定義することを意図したものである。

本発明の実施形態に基づいて構成された装置を説明する図である。本発明のセキュリティー開発モジュールの実施形態に関連する処理オペレーションを説明する図である。本発明の実施形態に基づいて使用される例として共通コードフォーマット中における汚染伝播をトレースするためにデータフローセキュリティーオペレーションを説明する図である。本発明のセキュリティーテストモジュールの実施形態に関連する処理オペレーションを説明する図である。本発明のセキュリティー監視モジュールの実施形態に関連する処理オペレーションを説明する図である。本発明の実施形態に基づいて構成されたセキュリティー監視モジュールのオペレーションを説明する図である。本発明の実施形態に基づいて構成されたセキュリティー監視モジュールのコンポーネントを説明する図である。

符号の説明

１００…装置、１０２…中央演算処理装置、１０４…入出力装置、１０６…バス、１０８…ネットワークインタフェース、１１０…ネットワーク、１１２…メモリー。

Claims

多種多様なプログラム命令フォーマットのうちのいずれか１つで書かれたプログラム命令のセキュリティー脆弱性に関する解析をプロセッサに実行させるための実行可能な命令を含むコンピュータ可読記憶媒体であって、
前記プログラム命令のフォーマットを共通フォーマットに変換し(200)、
前記共通フォーマットのプログラム命令からシステムモデルを導き出し(202)、
前記システムモデルに対し、静的な解析として、静的データフロー解析、字句解析、意味解析、及びプログラム制御フロー解析のうちのいずれか１つを実施し、それによって前記プログラム命令のセキュリティー脆弱性に関する情報を生成し(204)、
攻撃データベースからの既知のエクスプロイト及びユーザ定義エクスプロイトに関する情報、並びに前記静的な解析から得られた前記セキュリティー脆弱性に関する情報に基いて、前記プログラム命令の潜在的なセキュリティー脆弱性を識別し(300)、
前記潜在的なセキュリティー脆弱性を使用して、前記プログラム命令に対し動的脆弱性テストを適用し、
前記動的テスト中における前記プログラム命令の動作を解析し(308)、
前記解析の結果をレポートする(310)
ための実行可能な命令を備える、コンピュータ可読記憶媒体。
前記多種多様なプログラム命令フォーマットは、多種多様なソースフォーマットまたは実行可能なコード命令フォーマットを含む、請求項１に記載のコンピュータ可読記憶媒体。
前記多種多様なプログラム命令フォーマットは、多種多様なマシン命令フォーマットを含む、請求項１に記載のコンピュータ可読記憶媒体。
前記多種多様なプログラム命令フォーマットは、多種多様なプログラム環境設定ファイルフォーマットを含む、請求項１に記載のコンピュータ可読記憶媒体。
前記実行可能な命令が、前記プログラム命令から構成された複数のソフトウェアアプリケーションを備えるソフトウェアシステムに使用される、請求項１に記載のコンピュータ可読記憶媒体。
前記多種多様なプログラム命令フォーマットのうちのいずれか１つで書かれたプログラム命令のセキュリティー脆弱性に関する解析をプロセッサに実行させるための実行可能な命令は、
プログラム命令のセキュリティー監査を実行し(404)、
前記セキュリティー監査に基いて、センサーを前記プログラム命令の中に挿入し(400)、
前記プログラム命令を実行し、それによって、前記センサーが、セキュリティーイベントのストリームを生成し(406)、
セキュリティーイベントの前記ストリームを監視し(408)、
セキュリティー実施結果をレポートする(410)
ための実行可能な命令をさらに含む、請求項１に記載のコンピュータ可読記憶媒体。
多種多様なプログラム命令フォーマットのうちのいずれか１つで書かれたプログラム命令のセキュリティー脆弱性に関する解析をプロセッサに実行させるための実行可能な命令を含むコンピュータプログラムであって、
前記プログラム命令のフォーマットを共通フォーマットに変換し(200)、
前記共通フォーマットのプログラム命令からシステムモデルを導き出し(202)、
前記システムモデルに対し、静的な解析として、静的データフロー解析、字句解析、意味解析、及びプログラム制御フロー解析のうちのいずれか１つを実施し、それによって前記プログラム命令のセキュリティー脆弱性に関する情報を生成し(204)、
攻撃データベースからの既知のエクスプロイト及びユーザ定義エクスプロイトに関する情報、並びに前記静的な解析から得られた前記セキュリティー脆弱性に関する情報に基いて、前記プログラム命令の潜在的なセキュリティー脆弱性を識別し(300)、
前記潜在的なセキュリティー脆弱性を使用して、前記プログラム命令に対し動的脆弱性テストを適用し、
前記動的テスト中における前記プログラム命令の動作を解析し(308)、
前記解析の結果をレポートする(310)
ための実行可能な命令を備える、コンピュータプログラム。
前記多種多様なプログラム命令フォーマットは、多種多様なソースフォーマットまたは実行可能なコード命令フォーマットを含む、請求項７に記載のコンピュータプログラム。
前記多種多様なプログラム命令フォーマットは、多種多様なマシン命令フォーマットを含む、請求項７に記載のコンピュータプログラム。
前記多種多様なプログラム命令フォーマットは、多種多様なプログラム環境設定ファイルフォーマットを含む、請求項７に記載のコンピュータプログラム。
前記実行可能な命令が、前記プログラム命令から構成された複数のソフトウェアアプリケーションを備えるソフトウェアシステムに使用される、請求項７に記載のコンピュータプログラム。
前記多種多様なプログラム命令フォーマットのうちのいずれか１つで書かれたプログラム命令のセキュリティー脆弱性に関する解析をプロセッサに実行させるための実行可能な命令は、
プログラム命令のセキュリティー監査を実行し(404)、
前記セキュリティー監査に基いて、センサーを前記プログラム命令の中に挿入し(400)、
前記プログラム命令を実行し、それによって、前記センサーが、セキュリティーイベントのストリームを生成し(406)、
セキュリティーイベントの前記ストリームを監視し(408)、
セキュリティー実施結果をレポートする(410)
ための実行可能な命令をさらに含む、請求項７に記載のコンピュータプログラム。