特表 2018-503203 許容可能なアクティビティルールに基づく許容可能なアクティビティの決定

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2018-503203(P2018-503203A)

(43)【公表日】2018年2月1日

(54)【発明の名称】許容可能なアクティビティルールに基づく許容可能なアクティビティの決定

(51)【国際特許分類】

   G06F 21/55 20130101AFI20180105BHJP

   G06F 11/30 20060101ALI20180105BHJP

   G06F 11/34 20060101ALI20180105BHJP

【ＦＩ】

   G06F21/55 320

   G06F11/30 155

   G06F11/30 140A

   G06F11/34 152

【審査請求】有

【予備審査請求】未請求

【全頁数】18

(21)【出願番号】特願2017-547377(P2017-547377)

(86)(22)【出願日】2014年12月16日

(85)【翻訳文提出日】2017年5月31日

(86)【国際出願番号】US2014070594

(87)【国際公開番号】WO2016099458

(87)【国際公開日】20160623

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

２．ＪＡＶＡ

(71)【出願人】

【識別番号】317017140

【氏名又は名称】エントイット ソフトウェア エルエルシー

【氏名又は名称原語表記】ＥＮＴＩＴ ＳＯＦＴＷＡＲＥ ＬＬＣ

(74)【代理人】

【識別番号】100087642

【弁理士】

【氏名又は名称】古谷 聡

(74)【代理人】

【識別番号】100082946

【弁理士】

【氏名又は名称】大西 昭広

(74)【代理人】

【識別番号】100121061

【弁理士】

【氏名又は名称】西山 清春

(74)【代理人】

【識別番号】100195693

【弁理士】

【氏名又は名称】細井 玲

(72)【発明者】

【氏名】マドウ，マティアス

(72)【発明者】

【氏名】ヘイラーズ，ベンジャミン，セス

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042GA12

5B042JJ17

5B042KK04

5B042LA02

5B042MA08

5B042MA14

5B042MB05

5B042MC36

(57)【要約】

本書で開示する例示的な実施形態はアプリケーションにおける許容可能なアクティビティを決定することに関する。アプリケーションのアプリケーションプログラミングインターフェイス（API）がランタイムエージェントを使用して監視される。APIに関する情報がルールエンジンに提供される。許容可能なアクティビティを記述する一組のルールがルールエンジンから受信される。
【選択図】図２

【特許請求の範囲】

【請求項1】

ランタイムエージェントを使用してサーバにおけるアプリケーションの複数のアプリケーションプログラミングインタフェイス（API）を監視し、
該ランタイムエージェントにより、該複数のAPIの所定期間にわたる使用情報をルールエンジンへ提供し、
該ランタイムエージェントにより、該使用情報に基づいて許可する許容可能なアクティビティを記述する一組のルールを該ルールエンジンから受信し、
該ランタイムエージェントにおいて、前記複数のAPIのうちの１つがコールされたことを判定し、及び、
該複数のAPIのうちの該１つに関連するアクティビティが許容可能であるか否かを前記一組のルールに基づいて判定する
ことからなる方法。

【請求項2】

前記使用情報が、監視されるAPIがコールされるたびにAPIデータを含み、
該方法が更に、前記ルールエンジンにおいて、それぞれのAPIデータを複数のクラスタのうちの１つのクラスタへと分割することを含み、前記一組のルールが、該それぞれのクラスタに基づくものである、請求項１に記載の方法。

【請求項3】

前記複数のクラスタに密度推定を使用して正規表現を生成することを更に含み、
前記一組のルールがそれぞれの正規表現を含む、
請求項２に記載の方法。

【請求項4】

前記アクティビティが異常であるか否かを前記正規表現に基づいて判定し、
該異常の判定に基づいてセキュリティアクションを実行する
ことを更に含む、請求項３に記載の方法。

【請求項5】

前記使用情報が、少なくとも１つのデータベースに対するクエリを含み、前記アクティビティが別のクエリを含む、請求項２に記載の方法。

【請求項6】

前記複数のクラスタが、ｋ平均法（k-means clunstering）を使用して分割され、及びそれぞれのクエリの長さ、それぞれのクエリで使用される文字のタイプ、それぞれのクエリに関連する時間情報、及びそれぞれのクエリにおける構文の複雑さのうちの少なくとも１つに少なくとも部分的に基づいて分割される、請求項５に記載の方法。

【請求項7】

前記ルールエンジンが、他の複数のサーバで実行している前記アプリケーションの前記複数のAPIの更なる使用情報をそれぞれのランタイムエージェントを介して更に受信し、該更なる使用情報を使用して前記一組のルールを決定する、請求項２に記載の方法。

【請求項8】

前記アクティビティが、データベースからファイルを読み出すことを含む、請求項１に記載の方法。

【請求項9】

前記使用情報が、ブラウザにレンダリングされるデータを含み、前記アクティビティが、ブラウザ内にレンダリングされる他のデータを含む、請求項１に記載の方法。

【請求項10】

ルールエンジン及びサーバを備えたコンピューティングシステムであって、
該サーバが、
該サーバ上で実行すべきアプリケーションと、
ランタイムエージェントエンジンと
を含み、該ランタイムエージェントエンジンが、
前記アプリケーションの複数のアプリケーションプログラミングインタフェイス（API）を監視して該複数のAPIの使用情報を生成し、
所定期間にわたりそれぞれの使用情報を前記ルールエンジンに提供し、
該提供された使用情報に基づいて許容可能なアクティビティを記述する一組のルールを該ルールエンジンから受信し、
前記ランタイムエージェントエンジンにおいて、前記複数のAPIのうちの１つの別の使用を判定し、
該別の使用が前記一組のルールを満たしているか否かに基づいてセキュリティアクションを実行する、
コンピューティングシステム。

【請求項11】

前記ルールエンジンが、前記使用情報を複数のクラスタへと更に分割し、前記一組のルールのそれぞれが、該複数のクラスタのそれぞれに基づくものである、請求項１０に記載のコンピューティングシステム。

【請求項12】

前記ルールエンジンが、前記複数のクラスタのそれぞれに密度推定を使用して、前記一組のルールのそれぞれに含まれるそれぞれの正規表現を生成する、請求項１１に記載のコンピューティングシステム。

【請求項13】

前記ランタイムエージェントエンジンが、前記別の使用が異常であるか否かを前記それぞれの正規表現に基づいて更に判定する、請求項１２に記載のコンピューティングシステム。

【請求項14】

前記使用情報が少なくとも１つのデータベースに対するクエリを含み、前記別の使用が別のクエリを含み、前記複数のクラスタが、それぞれのクエリの長さ、それぞれのクエリで使用される文字のタイプ、それぞれのクエリに関連する時間情報、及びそれぞれのクエリにおける構文の複雑さのうちの少なくとも１つに少なくとも部分的に基づいてｋ平均法（k-means clunstering）を使用して分割される、請求項１１に記載のコンピューティングシステム。

【請求項15】

命令を格納した持続性マシン読み取り可能記憶媒体であって、該命令が、システムの少なくとも１つのプロセッサにより実行された場合に、
ウェブアプリケーションを実行し、
該アプリケーションの複数のアプリケーションプログラミングインタフェイス（API）をランタイムエージェントを使用して監視して、データベースに対する関連する複数のクエリを決定し、
一定期間にわたり該複数のクエリのそれぞれをルールエンジンへ提供し、
該複数のクエリに少なくとも部分的に基づいてクエリを許可するための許容可能なアクティビティを記述する一組のルールを前記ルールエンジンから受信し、
前記ランタイムエージェントにおいて前記データベースに対する別のクエリを決定し、及び、
前記データベースに対する前記クエリが前記一組のルールを満たしているか否かに基づいてセキュリティアクションを実行する
ことを前記システムに行わせるものであり、
前記一組のルールが、前記複数のクエリのそれぞれの複数のクラスタへのｋ平均法による分割（k-means clunstering）、及び該複数のクラスタのそれぞれからのそれぞれの正規表現の決定に基づくものであり、該一組のルールが該正規表現を含み、及び、
前記複数のクラスタが、それぞれのクエリの長さ、それぞれのクエリで使用される文字のタイプ、それぞれのクエリに関連する時間情報、及びそれぞれのクエリにおける構文の複雑さのうちの少なくとも１つに少なくとも部分的に基づいて分割される、
持続性マシン読み取り可能記憶媒体。

【発明の詳細な説明】

【背景技術】

【0001】

ソフトウェアセキュリティ検査は、ウェブアプリケーション等のアプリケーションの脆弱性を識別するために使用される。アプリケーションは、攻撃者の一般的なターゲットである。ネットワークセキュリティ及びセキュリティ検査は一定の防御を提供するが、かかるタイプの検査は何らかの悪意のあるアクティビティ（例えば、ゼロデイ攻撃）を見逃し得るものである。

【発明の概要】

【発明が解決しようとする課題】

【0002】

ウェブアプリケーションとは、ウェブブラウザ内で実行されるソフトウェアである。アクセスは、ウェブアプリケーションサーバにより提供される。ウェブアプリケーションは、ウェブアプリケーションのためのクライアントとして使用することができるウェブブラウザの普及によって普及してきた。しかし、ウェブアプリケーションは、様々な攻撃のターゲットとなっている。

【0003】

エンタープライズアプリケーションの数及び複雑さが増すにつれ、悪用のためのアタックサーフェスが増大し、該エンタープライズアプリケーションは無防備の状態のままとなる。アプリケーションを保護するための従来の方法は、その実施に多大な時間を要するものであり、及び開発中のソフトウェアに焦点を合わせたものである。かかる保護は、稼働中のアプリケーションを保護するものではない。更に、成功した違反（breaches）の大半がアプリケーション層で発生している場合、製品を保護すべく単純な境界防御（perimeter defense）を導入しても効果がないことは明らかである。

【0004】

RASP（Runtime Application Self-Protection）ソリューション並びにWAF（Web Application Firewall）は、攻撃から保護し及び通常のユーザトラフィックを通過させるために該ソリューションを手作業で微調整するために要する時間に悩まされるものである。手作業での微調整は、該ソリューションに大量のオーバーヘッドを付加し、並びに該ソリューションをヒューマンエラーを生じ易いものとする。かかるエラーの発生は、攻撃を通過させ、ひいては突破されてしまうことにより、該ソリューションを人々が使用できなくなること（逆もまた同様）に通じるものとなる。

【課題を解決するための手段】

【0005】

したがって、本書における様々な実施形態は、アプリケーション内からの攻撃を阻止するためのアプローチであって該アプローチを手作業で微調整する必要を低減させるアプローチについて説明する。リアルタイム攻撃を検出して阻止すべくランタイム環境でアクティビティを監視するためにランタイム解析技術が使用される。RASPソリューションの微調整は、良いトラフィックの特徴と悪いトラフィックの特徴を考慮に入れる。既知の攻撃ベクトルが存在する場合、RASPソリューションは、かかる既知の攻撃ベクトルを組み込む（ブラックリストに載せる）ことから開始することができる。

【0006】

しかし、今日、全ての攻撃ベクトルが既知となっている訳ではなく、このため、よりロバストなソリューションは、良いトラフィックを特徴付ける（ホワイトリストに載せる）ものとなる。これは、他のセキュリティ機構に加えて又はそれ自体で実行することが可能である。このアプローチにおける課題は、良いトラフィックがアプリケーション毎に異なる傾向にあることである。セキュリティアナリストは、手作業で良いトラフィックを特徴付けようとし、及び、通常は該特徴付けを、通常の状況で到来する傾向を有するものを観察することにより行うことになる。

【0007】

これは、訓練データに基づいて良いトラフィックを特徴付けることにより自動化することが可能である。これを実行するために、機械学習を使用することが可能である。特に、密度推定（density estimation）と併せてｋ平均法（k-means clustering）を使用することが可能である。十分に大きなサンプルセットが提供され及びデータが収束した場合、到来するトラフィックをチェックするために使用することができるｋ個のクラスタが入手可能となる。ｋ平均法は、プロトタイプベクトルの分布による確率密度関数のモデリングを可能とするベクトル量子化のためのアプローチである。該ｋ平均法によるアプローチは、（この場合、１つのアプリケーションの通常の使用となる）ｎ個の観察（observations）を同様の挙動のｋ個のクラスタへと分割するのに役立つものである。ここで、各観測は、最も近い「平均」を有するクラスタに属するものとなる。

【0008】

該観察は、ウェブアプリケーションを含む１つ以上のサーバ上で実行しているランタイムエージェントにより監視される複数のAPI（Application Programming Interface）からのものとすることが可能である。実施形態によっては、アプリケーションの実施は、該アプリケーションを複数のサーバにインストールし、及びロードバランサを使用して該アプリケーションを実行するサーバ間の負荷平衡を提供するように行うことが可能である。攻撃者のターゲットとなり得るアクションを実行するAPIを観察のため監視することが可能である。観察のために監視すべきAPIの例として、クエリの実行をコールするAPI、ウェブブラウザで何らかのレンダリングを行わせるAPIなどが挙げられる。

【0009】

一実施形態では、保護すべき脆弱性は、SQL（Structured Query Language）インジェクションである。この例では、データベースに対して実行される各クエリを記録し、十分な訓練データが利用可能である場合に該データをクラスタリングアルゴリズムを介して処理することが可能である。ｋ平均法アプローチの例は、該クラスタリングアルゴリズムの最終的な結果は、前記訓練データを含むｋ個のクラスタとなる。

【0010】

該クラスタが利用可能になると、異常（anomalies）を見出すためにアプリケーションに到来するトラフィックについて使用することができるルールを、密度推定を使用して生成することが可能である。この所与の例では、データベースに対して実行されることになる各クエリを最初にチェックして、これが異常であるか否かを確認することになる。該クエリが異常である場合には、デフォルトアクションを行って、該異常なクエリをデータベースに対して実行させることからアプリケーションを保護することができる。本書で説明するように、クエリ並びに他のAPIに関する情報は、アプリケーションの保護に資すべくアクションが異常であるか否かを決定することに資することができる。

【0011】

既述のように、本ソリューションは、正常なトラフィックが特定の特性を有し、及び正常なトラフィックが、到来するリクエストの大半である、という事実に基づくものである。一方、攻撃は、一般に不定期に出現し、及び正常なトラフィックとは異なる特性を有するものとなる。

【0012】

このソリューションは、様々な考え得るアプリケーションの脆弱性（例えば、SQLインジェクション、クロスサイトスクリプティング（XSS）、コマンドインジェクションなど）に使用することが可能である。アプリケーション自体のAPI上で動作するので、ランタイムエージェントは、WAFを使用することなくルールを生成するための更なる状況を提供することができる。

【0013】

本書で説明するように、本書でランタイムエージェントと称するソフトウェアプログラムは、アプリケーションにより実行される内部的な動作を監視するために使用される。ソフトウェアはハードウェアにより実行することができる。ランタイムエージェントは、アプリケーションの動作及び挙動を決定し、この情報をルールエンジンに提供することができる。該ランタイムエージェントはまた、ルールエンジンから受信したルールに対する将来のAPIコールを確認することを可能にする。

【図面の簡単な説明】

【0014】

【図1】一実施形態によるアプリケーションの許容可能なアクティビティを記述する一組のルールを決定し及び／又は使用するためのコンピューティングシステムを示すブロック図である。

【図2】異なる実施形態によるアプリケーションの許容可能なアクティビティを記述する一組のルールを決定し及び／又は使用するためのコンピューティングシステムを示すブロック図である。

【図3】一実施形態によるアプリケーションの許容可能なアクティビティを記述する一組のルールを決定し及び／又は実施するための方法を示すフローチャートである。

【図4】一実施形態によるアプリケーションの許容可能なアクティビティを記述する一組のルールのためのシード情報を提供すること及び該一組のルールを実施することが可能なコンピューティング装置を示すブロック図である。

【図5】一実施形態によるアプリケーションの許容可能なアクティビティを記述するルールを生成するための方法を示すフローチャートである。

【図6】一実施形態によるアプリケーションを監視するエージェントからのシード情報に基づいて該アプリケーションの許容可能なアクティビティを記述する一組のルールを生成することが可能なコンピューティング装置を示すブロック図である。

【発明を実施するための形態】

【0015】

図１及び図２は、様々な実施形態によるアプリケーションの許容可能なアクティビティを記述する一組のルールを決定し及び／又は使用するためのコンピューティングシステムを示すブロック図である。図１によれば、コンピューティングシステム100は、サーバ110a、データベース120、及びルールエンジン130を含むことができる。サーバは、アプリケーション142およびランタイムエージェントエンジン144を含むことができる。更に、図２に示すように、システム100は、他のサーバ110b-110n、並びに該サーバ110を装置170a-170nに接続する通信ネットワーク160とを更に含むことができる。更に、サーバ110aは、メモリ146、少なくとも１つのプロセッサ148、及び／又は入出力インタフェイス150を更に含むことができる。それぞれの装置110a-110n,170a-170nは、ノートブックコンピュータ、デスクトップコンピュータ、サーバ、ワークステーション、又は本開示の機能を実行することができる任意の他のコンピューティング装置とすることが可能である。特定の例では、サーバ140は、コンピュータネットワークを介したリクエストに応じて、ネットワークサービスを提供し又は該提供に資することができるシステムである。複数の装置間の通信は、リクエスト／レスポンスプロトコル（例えば、HTTP（Hyper-Text Transfer Protocol）またはその他の通信プロセスなど）を使用して実行することが可能である。更に、ルールエンジン130及び／又はデータベース120は、コンピューティング装置として実施することができる。

【0016】

サーバ110aは、アプリケーション142を含むことができる。該アプリケーション142は、装置170（例えば、クライアント）により使用することができる。 上述したように、アプリケーション142は、ウェブアプリケーション（例えば、ウェブブラウザ内でコンピュータにより実行することができるソフトウェア）とすることが可能である。Webアプリケーションは、ブラウザがサポートするプログラミング言語（例えば、JAVASCRIPT、HTML（HyperText Markup Language）、CSS（Cascading Style Sheets））で作成することができる。更に、Webアプリケーションフレームワーク（例えば、.NET、JavaEE）を使用してWebアプリケーションを実施することができる。ウェブアプリケーションの例として、電子メールアプリケーション、地図およびナビゲーションアプリケーション、銀行取引サイト、取引サイト、ニュースサイト、フォーラムなどが挙げられる。アプリケーション142は、１つ以上のデータベース120にアクセスすることができる。

【0017】

上述のように、アプリケーション142は、任意の適切なウェブベースのコンピュータ言語（とりわけ、JAVAまたは.NETなど）でエンコードすることが可能である。アプリケーション142は、適切なソフトウェアフレームワーク（例えば、Struts、Struts2、ASP.NET MVC、Oracle WebLogic、及びSpring MVCなど）内で動作することが可能である。該ソフトウェアフレームワークは、汎用的な機能を提供する一組の共通コードモジュールを含み、該共通コードモジュールは、特定の機能を提供するためにユーザーコードにより選択的にオーバーライドされ又は特殊化される（specialized）ことが可能である。アプリケーション142は、Java仮想マシン（JVM）、共通言語ランタイム（CLR）、又は他のランタイム環境の１つ以上のインスタンスを実行するよう構成することが可能である。ソフトウェアフレームワークまたはランタイム環境の共通コードモジュールにより提供されるプログラミング命令は、コンテナコードと称することが可能である。

【0018】

アプリケーション142は、１つ以上のサーバ110と複数の装置170、データベース120、及び／又はルールエンジン130との間の通信を可能にするためのネットワークインタフェイスを含むことができる。該ネットワークインタフェイスは、アプリケーション142へのアクセスを提供することができるが、アプリケーション142のアタックサーフェスを露呈させるものでもある。ネットワークインタフェイスを介したアプリケーション142と他の装置との間の通信は、装置170からアプリケーション142に発行されたHTTPリクエストと、アプリケーション142から装置170に発行されたHTTPレスポンスとを介して行うことが可能である。アプリケーション142をターゲットとするリクエストは、アプリケーションリクエストと称することが可能であり、アプリケーション142から受信したレスポンスは、アプリケーションレスポンスと称することが可能である。実施形態によっては、通信は、アプリケーション142と装置170との間の通信、並びに他の複数の装置（例えば、データベース120）、他のサーバ110b-110n、及びルールエンジン130など）との通信を含む。

【0019】

アプリケーション142は、ファイルシステム、データベース120、及びアプリケーション142により使用される他のリソースと結合することが可能である。ファイルシステムは、アプリケーション142により使用されるデータおよびプログラム、並びにユーザによりリクエストされ得るデータ（例えば、HTTPページ、ソフトウェアプログラム、メディアファイルなど）を含むことが可能である。

【0020】

ランタイムエージェントエンジン144は、アプリケーション142の実行環境内で動作することができ、及びアプリケーション142により実行される内部的な動作にアクセスすることができる。例えば、ランタイムエージェントエンジン144は、特定の例では、アプリケーション142のバイトコードの変更を、様々なプログラムポイントでJAVAクラス等の追加のコードを注入することにより行うことが可能である。該注入されたコードは、アプリケーション142を観察するモニタとして機能する。該注入されたモニタコードは、アプリケーション142内の戦略的なプログラムポイント（例えば、URLパラメータの読み出し、ファイルシステムへの書き込み、クエリの実行、ウェブブラウザに対するレンダリングの指示といった特定の動作を実行するアプリケーションプログラミングインタフェイス（API）コール）に配置することが可能である。アプリケーション142内のかかるプログラムポイントが実行されるときには必ず、モニタは、ランタイムエージェントエンジン144により提供されるサービスを呼び出して、アプリケーション142により実行される動作を記録する。ランタイムエージェントエンジンは、アプリケーション142の内部的な動作に関して収集された情報を格納するためのバッファに結合することが可能である。該バッファは、収集されたデータを格納するために使用することが可能である。該バッファは、ハードディスク、SSD（Solid State Drive）等の不揮発性記憶媒体に格納することが可能である。該バッファ内の情報は送信することが可能である。例えば、ランタイムエージェントエンジン144により収集された情報は、ルールエンジン130へ送信することができる。

【0021】

ランタイムエージェントエンジン144はまた、ネットワークを介したランタイムエージェントエンジン144とルールエンジン130との間の通信を可能にするための更なるネットワークインターフェイスを含むことが可能である。

【0022】

アプリケーション142、複数のサーバ110、及び／又は１つ以上のデータベース120を保護するために複数のメカニズムを使用することができる。かかる保護の１つとして、ランタイムエージェントエンジン144を使用してアプリケーション142を監視して動的な保護を提供することが挙げられる。ランタイムエージェントエンジン144は、特定のタイプのアクティビティを監視するよう構成することができる。例えば、ランタイムエージェントエンジン144は、アプリケーション142の複数のAPIを監視して、それらAPIの使用情報を生成することができる。これは、バッファに格納され、及び（例えば、ネットワーク接続を介して）ルールエンジン130に提供される。実施形態によっては、ランタイムエージェントエンジン144は、ルールエンジン130のアドレス情報を有することができ、及び（例えば、アプリケーション142のAPIまたは別のアプローチを介して）サーバの構成要素にアクセスすることにより情報を提供するよう構成することができる。更に、該アプリケーションを複数のサーバ110上で実行することができ、ルールエンジン130は、該アプリケーションの複数のインスタンスから使用情報を受信することができる。該使用情報は、一定の期間にわたって提供することができる。該期間は、アプリケーション142についての基本的な量（baseline amount）の情報を提供するための一定の時間とすることができる。

【0023】

上述のように、このアプローチの複数の観察のうちの１つは、アプリケーション142が特定の態様で通常動作するものとなる。この期間は、情報のサンプルサイズが、アプリケーション142の通常のアクティビティを決定するのに十分な大きさを有することを可能にするものである。

【0024】

ルールエンジン130は、前記使用情報からルールを生成し、及び該ルールを更新を介してランタイムエージェントエンジン144に送ることができる。該ルールは、機械学習アプローチを使用して生成することができる。一実施形態では、ルールエンジン130は、該使用情報を複数のクラスタへと更に分割し、この場合、それぞれのルールはそれぞれのクラスタに基づくものとなる。ルールエンジン130は、サーバ110とは別個のコンピューティング装置上で実施することができる。かかる実施の利点は、ルールを生成するために使用される分析に使用されるリソースを分離することにある。更に、実施形態によっては、ルールエンジン130は、複数の異なるアプリケーションのためのルールを生成することができる。また、実施形態によっては、ルールエンジン130は、複数のサーバ上でインスタンスとして動作している同じアプリケーションのためのルールを生成することができる。

【0025】

ｋ平均法アプローチを用いることができる。このアプローチは、アプリケーションにとって正常と見なされる可能性のある複数の異なるタイプのアクティビティを見出し、それらを同様のクラスタに入れるという利点を有する。一例では、（a）ｋ個の最初の「手段」が、分割（partitioning）スキーム（例えば、Random Partition、Forgyなど）を介してソートされる。特定の例では、観察は、特定のイベント（例えばAPIの使用）が発生したときの特定の情報（例えば、時間、変数/パラメータのサイズ、変数/パラメータの複雑さ、使用される変数/パラメータ、特定のクエリのソース、他のコンテキスト情報など）の状態を記述するデータである。次いで、（b）各観測を最も近い平均に関連付けることによりｋ個のクラスタが生成される。次いで、（c）ｋ個のクラスタのそれぞれの重心（centroid）が新たな平均となることができる。収束に達するまでアプローチ（b）,（c）を繰り返すことができる。実施形態によっては、収束は、平均が最後の反復の閾値内にあるときに生じ得る。他の例では、収束は、複数の反復の手段が同一である場合に生じる。ｋ平均法アプローチの様々な機械学習による変形例（例えば、ｋ-メジアン（k-medians）クラスタリング、Fuzzy C-Meansクラスタリング、ガウス混合（Gaussian mixture）モデルなど）が存在する。観察には特定の特性を用いることができる。例えば、使用情報および特性は、少なくとも１つのデータベースに対するクエリといった特定のAPIに関する情報を含むことができる。複数のクラスタは、以下の複数の特徴のうちの少なくとも１つに少なくとも部分的に基づいてｋ平均法を使用して分割される：それぞれのクエリの長さ、それぞれのクエリで使用される文字のタイプ、それぞれのクエリに関連付けられた時間情報、及びそれぞれのクエリにおける構文の複雑さなど。実施形態によっては、他のAPIの同様の特徴を使用することができる。例えば、１つ以上のパラメータを観測として使用することができる。この特性を使用して、調査すべき次元を設定することができる。

【0026】

SQLインジェクション又はコマンドインジェクションなどの脆弱性にとって、クエリがどのように見えるかは重要である。このため、特性は、クエリに基づくものとすることが可能である。一例として、クエリの構文、長さ、タイミング情報、特殊文字（例えば、記号）の長さなどが挙げられる。アクティビティの中には特定の時点で発生する（例えば、金曜日の午後５時にバックアップする）ものがあり、及び、該アクティビティはその時点では正常とみなされるが別の時点では異常とみなされる可能性があるため、タイミング情報は有用なものとなり得る。

【0027】

密度推定は、クラスタのサンプルセットと比較して異常を判定するためにルールエンジン130により使用することができる。確率および統計では、密度推定は、観測に基づいて基礎となる確率密度関数の推定値を構築することである。更に、確率密度関数は、変数が与えられた値をとる可能性を記述する関数である。前記サンプルセットは、ベースラインデータに基づいて正常または異常でないと仮定することができる。実施形態によっては、正常なベースラインの確保に資するために、アプリケーションに他の制御（例えば、他のセキュリティ手段）を使用することができる。目標は、アクティビティ（例えば、クエリまたはAPIの使用）が適切であり又は異常でない確率を予測するモデルを構築することである。ｋ平均法の出力は、同様のデータの複数のグループである。かかる各クラスタは、密度推定によって処理されて、特性に基づいてクラスタを記述する正規表現を生成することができる。別個のAPIに対して別個のルールを作成することができる。更に、該クラスタリングおよび密度推定は、監視される各API毎に行うことができる。異常検出のために、各クラスタ毎にモデルp（x）を作成することができる。これは、正規表現に変換することができる。実施形態によっては、特定のAPIについて、各クラスタ毎の各モデルを正規表現に変換し、及び複数の該正規表現を論理和により結合することが可能である。

【0028】

１つ以上の正規表現は、一組のルールの一部とみなすことができる。所与のアクティビティが、該正規表現のモデル内にある場合、該アクティビティは異常ではないとみなされる。該アクティビティが該正規表現のモデル内にない場合には、該アクティビティは異常とみなされる。実施形態によっては、該正規表現は、p（x）のモデルがε未満であることに基づくものとすることができる。実施形態によっては、該εは、特定のアプリケーション及び／又はAPIについてユーザにより決定することができる。更に、モデルは複数のレベルを有することができる。一実施形態では、p（x）＜ε1は異常を示さず、ε1＜p（x）＜ε2は異常の可能性があることを示し、p（x）＞ε2は異常を示すことができる。正規表現は、各モデル範囲に関連付けることができる。別の実施形態では、モデルは、正規表現に変換される必要はなく、監視される特性について実行されるべきステップとして処理されて、それぞれのモデルに適合するか否かを判定することが可能である。

【0029】

ランタイムエージェントエンジン144は、ルールを受信することができる。該ルールは、特定のアクティビティ（例えば、APIコール）が実行されたときに許可される許容可能なアクティビティを記述することができる。許容可能なアクティビティを記述するルールは、一定期間の使用情報に従って異常でないアクティビティを記述するルールである。該ルールは、アクティビティが該ルールのパラメータを満たさない場合に、該アクティビティを異常としてマークすることができる。一実施形態では、該ルールは、特定のAPIをチェックするための正規表現という形をとることが可能である。アクティビティが正規表現と照合される場合、該アクティビティがその標準から逸脱する場合は異常と見なされ、そうでない場合は異常でないとみなされる。

【0030】

監視されている複数のAPIのうちの１つの新たな使用が発生すると、ランタイムエージェントエンジン144は、そのアクティビティを監視することができる。該APIの使用状況をルールと照合することができる。該アクティビティが異常でない場合、その処理を続行することができる。該アクティビティが異常であるとみなされた場合には、セキュリティアクションを実行することができる。 該セキュリティアクションは、悪意のあるアクティビティを阻止し及び／又は監視するアクションとすることができる。例えば、セキュリティアクションは、APIの使用の阻止、エラーメッセージの送信、アクティビティの記録などを実行することができる。

【0031】

一実施形態では、アプリケーション142は、名前の入力フィールド及び社会保障番号の入力を有するウェブページを含むことができる。APIは、この情報に基づいてデータベースに対するクエリを生成することができる。該アプリケーションの通常の使用は、社会保障番号フィールドが、変数として、通常９桁の数字を有することを示すことができる。更に、該アプリケーションの通常の使用は、名前フィールドが、変数として、特定の範囲の個数のアルファベット文字及び／又はスペースを通常有することを示すことができる。通常の使用のためのモデルは、クラスタリングアルゴリズムにより処理されるAPI情報および密度推定による更なる処理を含む訓練データに基づくものとすることができる。最初のクラスタは、社会保障番号のための９桁と空白のない１つの文字列とを含むことが可能である。第２のクラスタは、社会保障番号のための９桁と（文字列と文字列との間にスペースを有する）２つの文字列とを含むことができる。第３のクラスタは、社会保障番号のための９桁と３つの文字列（すなわち、第１の文字列、１つのスペース、頭文字を示す長さ１の第２の文字列、及び第３の文字列）とを含む。他のかかるクラスタも同様に形成することが可能である。密度推定は、各クラスタについて機能して複数のクラスタをモデル化することができ、例えば、ルールは、社会保障番号フィールドが９文字のみであってその文字が数字である必要があることを含むことが可能であり、同時に、名前に関する文字列に適合するようその他の制限を作成することが可能である。密度推定に従ってルール（例えば、正規表現）を作成することが可能である。

【0032】

クエリを実行するためにAPIが呼び出されると、ランタイムエージェントエンジン144はそのフィールドをルールと比較して該ルールを満たしているか否かを判断することができる。（例えば、社会保障番号フィールドにスクリプトを注入する試みが含まれているため）該ルールを満たしていない場合、そのアクセスの試行は異常とみなされ、セキュリティアクションを実行する（例えば、アクションの実行を許可しない、管理者に通知する、ログを採取する）ことができる。

【0033】

通信ネットワーク160は、有線通信、無線通信、又はそれらの組み合わせを使用することができる。更に、通信ネットワーク160は、複数の副通信ネットワーク（例えば、データネットワーク、無線ネットワーク、電話ネットワークなど）を含むことができる。かかるネットワークは、例えば、インターネット等の公衆データネットワーク、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、メトロポリタンエリアネットワーク（MAN）、ケーブルネットワーク、光ファイバネットワーク、これらの組み合わせなどを含むことができる。特定の実施形態では、無線ネットワークは、セルラーネットワーク、衛星通信、無線LANなどを含むことができる。更に、通信ネットワーク160は、複数の装置間の直接的なネットワーク接続という形をとることができる。様々な通信構造およびインフラストラクチャを利用して１つ以上の通信ネットワークを実施することができる。

【0034】

例えば、装置130,170は、１つの通信プロトコルまたは複数のプロトコルを介した通信ネットワーク160へのアクセスを用いて、互いに及び他の構成要素と通信する。プロトコルは、通信ネットワーク160の複数のノードが他の複数のノードと対話する態様を定義する一組のルールとすることができる。更に、複数のネットワークノード間の通信は、個別のデータパケットを交換し又はメッセージを送信することにより実施することができる。パケットは、プロトコルに関連するヘッダ情報（例えば、連絡すべき１つ以上のネットワークノードの位置に関する情報）並びにペイロード情報を含むことができる。

【0035】

本書で説明するエンジン、モジュール、および部品は、１つ以上の装置間に分散させることが可能である。エンジン142,144,130は、本書で提供する複数の機能を実行するためのハードウェア及び／又はハードウェアとプログラミングの組み合わせを含む。更に、モジュールは、本書で提供するハードウェアにより実行されるべき複数のプログラミング機能及び／又は複数のプログラミング機能の組み合せを含むことができる。エンジン及びモジュールについて論じる場合、エンジンに起因する機能は、対応するモジュールにも起因し得るものであり、逆もまた同様である、ということに留意されたい。更に、特定のモジュール及び／又はエンジンに起因する機能は、別のモジュール及び／又はエンジンを使用して実施することも可能である。モジュールおよびエンジンの例として、ランタイムエージェントエンジン144及びルールエンジン130が挙げられる。

【0036】

命令の読み出し及び実行に適した中央処理装置（CPU）またはマイクロプロセッサなどのプロセッサ及び／又は電子回路は、本書で説明するエンジン及び／又はモジュールの機能を実行するよう構成することができる。特定のシナリオでは、命令及び／又はその他の情報（例えば、ルール）をメモリに含めることができる。実施形態によっては、入出力インターフェースを複数の装置により更に提供することが可能である。例えば、キーボード、センサ、タッチインタフェイス、マウス、マイクなどの入力装置を利用して、装置の周辺環境から入力を受信することができる。更に、ディスプレイなどの出力装置を利用して、ユーザに情報を提示することができる。出力装置の例として、スピーカ、表示装置、増幅器などが挙げられる。更に、特定の実施形態では、幾つかの構成要素を利用して、本書に記載する他の構成要素の機能を実施することができる。ネットワーク通信装置又は無線装置等の通信装置といった入出力装置もまた、入出力インターフェースを使用することができる装置と考えることができる。

【0037】

複数のエンジン／モジュールの各々は、例えば、本書で説明する機能を実施するための電子回路を含むハードウェアデバイスを含むことが可能である。追加的に又は代替的に、各モジュールは、コンピューティング装置のマシン読み取り可能記憶媒体上にエンコードされプロセッサにより実行可能な一連の命令として実施することが可能である。実施形態によっては、一部のモジュールがハードウェアデバイスとして実施され、他のモジュールがマシン読み取り可能記憶媒体上にエンコードされた実行可能命令として実施されることに留意されたい。

【0038】

図３は、一実施例による、アプリケーションの許容可能なアクティビティを記述する一組のルールを決定及び／又は実施するための方法を示すフローチャートである。図４は、一実施形態による、アプリケーションの許容可能なアクティビティを記述する一組のルールのためのシード情報を提供し及び該ルールを実施することができるコンピューティング装置を示すブロック図である。方法300の実行については、コンピューティング装置400に関して以下で説明するが、該方法300の実行のために他の適当な構成要素（例えば、コンピューティングシステム100）を利用することができる。更に、方法300を実行するための構成要素は、複数の装置間に分散させることが可能である。方法300は、記憶媒体420等のマシン読み取り可能記憶媒体上に格納された実行可能命令という形で及び／又は電子回路という形で実施することが可能である。

【0039】

コンピューティング装置400は、例えば、プロセッサ410と、アプリケーションを監視し及びルールを使用して該アプリケーションを保護するための命令422,424を含むマシン読み取り可能記憶媒体420とを含む。コンピューティング装置400は、例えば、ノートブックコンピュータ、デスクトップコンピュータ、ワークステーション、サーバ、又は本書で説明する機能を実行することができる他の任意のコンピューティング装置とすることが可能である。

【0040】

プロセッサ410は、少なくとも１つの中央処理装置（CPU）、少なくとも１つの半導体ベースのマイクロプロセッサ、少なくとも１つのグラフィクス処理装置（GPU）、マシン読み取り可能記憶媒体420に格納された命令の読み出し及び実行に適した他のハードウェア装置、またはそれらの組み合わせとすることが可能である。例えば、プロセッサ410は、１チップ上に複数のコアを含むことが可能であり、複数のチップにわたり複数のコアを含むことが可能であり、複数のデバイスにわたり複数のコアを含むことが可能であり（例えば、コンピューティング装置400が複数のノード装置を含む場合）、又はそれらの組み合わせを含むことが可能である。プロセッサ410は、方法300を実施するために命令422,424をフェッチし、デコードし、および実行することが可能である。命令の読み出し及び実行に代えて又はそれらに加えて、プロセッサ410は、命令422,424の機能を実行するための複数の電子的な構成要素を含む、少なくとも１つの集積回路（IC）、他の制御ロジック、他の電子回路、又はそれらの組み合わせを含むことが可能である。

【0041】

マシン読み取り可能記憶媒体420は、実行可能命令を収容し又は格納する任意の電子的、磁気的、光学的、又はその他の物理的な記憶装置とすることが可能である。このため、マシン読み取り可能記憶媒体は、例えば、ランダムアクセスメモリ（RAM）、EEPROM（Electrically Erasable Programmable Read-Only Memory）、ストレージドライブ、CD-ROM（Compact Disc Read Only Memory）などとすることが可能である。このため、マシン読み取り可能記憶媒体は持続性のものとすることができる。本書で詳細に説明するように、マシン読み取り可能記憶媒体420には、ウェブアプリケーションを保護するための一連の実行可能命令をエンコードすることが可能である。更に、実施形態によっては、様々な命令422,424を異なる媒体に格納することが可能である。

【0042】

コンピューティングデバイス400は、アプリケーション命令422を実行して、ウェブアプリケーションをクライアント等の他の装置に提供することができる。かかるクライアントは、ウェブブラウザ又はローカルアプリケーション等のソフトウェアを使用して該ウェブアプリケーションにアクセスすることができる。

【0043】

ステップ302で、ランタイムエージェント命令424を実行して、アプリケーションのAPIを監視することができる。ランタイムエージェント命令424は、ランタイムエージェントを実施するために実行することができる。使用情報を収集することができる。例えば、特定のAPIを使用してクエリが処理される場合、該APIの識別子及び該クエリを該使用情報に含めることが可能である。別の実施形態では、監視されるAPIは、ブラウザにレンダリングされるデータを含み、これを使用情報に含めることが可能である。かかるタイプのAPIの監視は、クロスサイトスクリプティング（XSS）から保護するために使用することができる。 XSSは、攻撃者が他のユーザーにより閲覧されるウェブページにクライアントサイドスクリプトを注入する脆弱性の一種である。レンダリングされるものを監視することは、XSSから保護するための１つのアプローチとなり得る。

【0044】

ステップ304で、ランタイムエージェント命令424を実行して、一定期間にわたる使用情報をルールエンジンへ提供することができる。一実施形態では、ルールエンジンは、コンピューティング装置600等のコンピューティング装置上で実施される。該使用情報の提供は、複数回発生することが可能である。例えば、第１組の使用情報でバッファを満たして送信することが可能である。次いで、第２組の使用情報を提供することが可能である（以下同様）。

【0045】

ルールエンジンは、本書で詳述するように、提供された情報からルールを生成することが可能である。ルールエンジンは、該ルールをランタイムエージェントへ送信することが可能である。ステップ306で、ランタイムエージェントは一組の該ルールを受信することが可能である。上述のように、該ルールは、続行を許可する許容可能なアクティビティを記述することが可能である。該ルールは、少なくとも部分的に、使用情報に基づくものである。

【0046】

ランタイムエージェントは、アプリケーションの動作を監視し続けることが可能である。更に、APIがコールされた際に、その使用をルールと照合することが可能である。このため、ランタイムエージェントは、監視される複数のAPIのうちの１つがコールされたことを判定することが可能である（308）。

【0047】

ステップ310で、ランタイムエージェントは、APIに関連するアクティビティが許容可能であるか否かを一組のルールに基づいて判定することができる。上記のように、一実施形態では、アプリケーションの通常のアクティビティに基づいて（例えば、ルールまたは正規表現と照合することにより）アクティビティが異常であるか否かを判定することができる。 監視し照合することができるアクティビティの例として、少なくとも１つのデータベースに対するクエリ、１つのデータベースからの読み出し、１つのデータベースへの書き込み、ブラウザへのレンダリングなどが挙げられる。

【0048】

図５は、一実施例による、アプリケーションの許容可能なアクティビティを記述するルールを生成するための方法を示すフローチャートである。図６は、一実施例による、アプリケーションを監視するエージェントからのシード情報に基づいてアプリケーションの許容可能なアクティビティを記述する一組のルールを生成することができるコンピューティング装置を示すブロック図である。方法500の実行は、コンピューティングデバイス600に関して以下で説明するが、方法500の実行のために他の適当な構成要素（例えば、コンピューティングシステム100、ルールエンジン130など）を利用することが可能である。更に、方法500を実行するための構成要素は、複数の装置にわたって分散させることが可能である。方法500は、記憶媒体620等のマシン読み取り可能記憶媒体上に格納された実行可能命令という形で、及び／又は電子回路という形で、実施することが可能である。

【0049】

コンピューティングデバイス600は、例えば、プロセッサ610と、アプリケーションを保護するためのルールを生成するための命令622,624を含むマシン読み取り可能記憶媒体620とを含む。コンピューティング装置600は、例えば、ノートブックコンピュータ、デスクトップコンピュータ、ワークステーション、サーバ、または本書で説明する機能を実行することができる他の任意のコンピューティング装置とすることが可能である。

【0050】

プロセッサ610は、少なくとも１つの中央処理装置（CPU）、少なくとも１つの半導体ベースのマイクロプロセッサ、少なくとも１つのグラフィクス処理装置（GPU）、マシン読み取り可能記憶媒体620に格納された命令の読み出し及び実行に適した他のハードウェア装置、又はそれらの組み合わせとすることが可能である。例えば、プロセッサ610は、１チップ上に複数のコアを含むこと、複数のチップにわたり複数のコアを含むこと、複数のデバイスにわたり複数のコアを含むこと（例えば、コンピューティング装置600が複数のノード装置を含む場合）、又はそれらの組み合わせを含むことが可能である。プロセッサ610は、方法500を実施するために、命令622,624をフェッチし、デコードし、及び実行することが可能である。プロセッサ610は、命令の読み出しおよび実行に代えて又はそれらに加えて、命令622,624の機能を実行するための複数の電子的な構成要素を含む、少なくとも１つの集積回路（IC）、他の制御ロジック、他の電子回路、又はそれらの組み合わせを含むことが可能である。

【0051】

マシン読み取り可能記憶媒体620は、実行可能命令を収容し又は格納する任意の電子的、磁気的、光学的、またはその他の物理的な記憶装置とすることが可能である。このため、マシン読み取り可能記憶媒体は、例えば、ランダムアクセスメモリ（RAM）、EEPROM（Electrically Erasable Programmable Read-Only Memory）、ストレージドライブ、CD-ROM（Compact Disc Read Only Memory）などとすることが可能である。このため、マシン読み取り可能記憶媒体は持続性のものとすることが可能である。本書で詳細に説明するように、マシン読み取り可能記憶媒体620には、セキュリティテストを実行するための一連の実行可能命令をエンコードすることが可能である。

【0052】

ステップ502で、コンピューティング装置600は、使用情報を受信することができる。該使用情報は、１つ以上のサーバからのアプリケーションの監視されるAPIについてのAPIデータを含むことができる。上述のように、該APIデータは、クエリ、データベースへのアクセスなどに関する情報を含むことが可能である。

【0053】

ステップ504で、該使用情報を複数のクラスタに分割することができる。 上述のように、該分割は、プロセッサにより実行される機械学習アルゴリズムを介して行うことが可能である。分割アプローチの一例としてｋ平均法が挙げられる。上述のように、該クラスタリングに基づいてルールを生成することができる。更に、上述のように、該クラスタリングは、クエリの長さ、クエリ内の文字のタイプ、またはAPIの使用時に使用されるパラメータ、APIの使用に関連する時間情報、構文の複雑さといった、API／クエリからの特定の特性に基づくものとすることが可能である。

【0054】

ステップ506で、クラスタに密度推定を使用してルールを生成する。実施形態によっては、ルールは正規表現という形をとることが可能である。このため、一組のルールは複数の正規表現を含むことが可能である。かかるルールは、１つ以上のサーバ上のアプリケーションのインスタンスを監視し保護するランタイムエージェントに返すことができる（508）。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】