(57)【要約】  ロギングシステムはイベントレシーバと記憶マネージャとを含む。イベントレシーバはログデータを受信し処理し、データ“チャンク”を出力する。マネージャはデータチャンクを受信し、クエリーできるよう該データチャンクを記憶する。該レシーバは、イベントを記憶するバッファと該バッファの記憶内容に関するメタデータを記憶するメタデータ構造体を含む。メタデータは、レシーバに関連付けられたユニークな識別子、該バッファ内におけるイベントの数、並びに、各“対象フィールド”毎に該バッファに記憶されたすべてのイベントにわたる該フィールドの数値範囲を示す最小値と最大値を含む。チャンクは、メタデータ構造体とバッファの記憶内容の圧縮バージョンを含む。イベントデータに対してクエリーを行う場合、メタデータ構造体は検索インデックスとして機能する。ロギングシステムはセキュリティ情報／イベント管理(SIEM)システムと共に使用され得る。【選択図】          図３
2010515172.tif 000002
【特許請求の範囲】
【請求項１】
ログデータを処理するための方法であって、
各々が１または複数のフィールドを含む複数のイベントからなるログデータを受信するステップと、
前記複数のイベントの各イベント毎に、
該イベントをバッファに記憶するステップと、
前記バッファの記憶内容についての情報からなるメタデータ構造体をアップデートするステップであって、前記バッファの記憶内容についての情報が、該バッファに記憶されたすべてのイベントのうちの第1のフィールドの最小値を示す第1の最小値を含む前記ステップと、
を具備する方法。
【請求項２】
前記バッファの記憶内容についての情報が、該バッファに記憶されたすべてのイベントのうちの前記第1のフィールドの最大値を示す第1の最大値を含む請求項1に記載の方法。
【請求項３】
前記バッファの記憶内容についての情報が、該バッファに記憶されたすべてのイベントのうちの第2のフィールドの最小値を示す第2の最小値を含む請求項1に記載の方法。
【請求項４】
前記バッファの記憶内容についての情報が、該バッファに記憶された多数のイベントをさらに含む請求項1に記載の方法。
【請求項５】
第1のトリガ条件に応じて、前記メタデータ構造体の記憶内容に基づき、さらに前記バッファの記憶内容に基づき、データチャンクを生成するステップをさらに具備した請求項1に記載の方法。
【請求項６】
前記第1のトリガ条件が、バッファ使用しきい値に基づく、または、タイムアウトウィンドウに基づくものである請求項5に記載の方法。
む請求項1に記載の方法。
【請求項７】
第2のトリガ条件に応じて、前記データチャンクによって使用された記憶スペースを再生するステップをさらに具備した請求項5に記載の方法。
【請求項８】
前記第2のトリガ条件が、前記データチャンクに関連付けられた保持ポリシーに基づくものである請求項7に記載の方法。
【請求項９】
前記第2のトリガ条件が、ディスクスペース使用しきい値に基づく、または、前記チャンクを保持する最大時間に基づくものである請求項7に記載の方法。
【請求項１０】
前記複数のイベントの各イベント毎に、
前記イベントが何時受信されたのかを判定するステップと、
前記イベントが何時受信されたのかを示すタイムスタンプを前記バッファに記憶するステップと
をさらに具備した請求項1に記載の方法。
【請求項１１】
前記イベントをバッファに記憶するステップが、該イベントを前記バッファの記憶内容に付加するステップを含む請求項1に記載の方法。
【請求項１２】
前記メタデータ構造体の記憶内容を含むデータチャンク、および、前記バッファの記憶内容の圧縮バージョンを生成するステップをさらに具備した請求項1に記載の方法。
【請求項１３】
前記データチャンクが、ファイル署名またはバージョン識別子をさらに含む請求項12に記載の方法。
【請求項１４】
前記データチャンクが、前記バッファの記憶内容のメッセージダイジェストをさらに含む請求項12に記載の方法。
【請求項１５】
1または複数の検索語のセットを含む検索クエリーを受信するステップと、
前記検索語のセットから、前記メタデータ構造体に含まれた情報に関する１または複数の検索語を特定するステップと、
各データチャンク毎に、特定された前記検索語と前記データチャンク内に含まれた前記メタデータ構造体の記憶内容と比較することによって、１または複数のデータチャンクを検索するステップと、
をさらに具備した請求項12に記載の方法。
【請求項１６】
前記特定された検索語を満足させる各データチャンク毎に、
該データチャンクを複数のイベントに分解するステップと、
前記複数のイベントの各イベント毎に、前記検索語のセットと前記イベントとを比較するステップと、
をさらに具備した請求項15に記載の方法。
【請求項１７】
ログデータを処理するためのコンピュータプログラム製品であって、該コンピュータプログラム製品は、方法を実行するためのコンピュータプログラムコードを含むコンピュータによって読み取り可能な媒体からなり、該方法が、
各々が１または複数のフィールドを含む複数のイベントからなるログデータを受信するステップと、
前記複数のイベントの各イベント毎に、
該イベントをバッファに記憶するステップと、
前記バッファの記憶内容についての情報からなるメタデータ構造体をアップデートするステッ
プであって、前記バッファの記憶内容についての情報が、該バッファに記憶されたすべてのイベントのうちの第1のフィールドの最小値を示す第1の最小値を含むものと、
を具備する方法。
【請求項１８】
ログデータを処理するための装置であって、
各々が１または複数のフィールドを含む複数のイベントからなるログデータを受信する受信モジュールと、
前記複数のイベントの各イベント毎に、該イベントをバッファに記憶するバッファモジュールと、
前記複数のイベントの各イベント毎に、前記バッファの記憶内容についての情報からなるメタデータ構造体をアップデートするメタデータモジュールであって、前記バッファの記憶内容についての情報が、該バッファに記憶されたすべてのイベントのうちの第1のフィールドの最小値を示す第1の最小値を含むものと、
を具備する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の説明
本出願は、2006年12月28日に出願された米国特許仮出願No.60／882,289 (これは、その出典を記載することによって本明細書の一部とする)の優先権を主張するものである。
【０００２】
本発明は、セキュリティ情報／イベント管理(SIMまたはSIEM)に関し、特に、クエリーをサポートしながらセキュリティ情報／イベントを効率的に記憶する技術に関する。
【背景技術】
【０００３】
セキュリティ情報／イベント管理(SIMまたはSIEM)の分野は、概ね、1)ネットワークおよびネットワークデバイスから、ネットワーク動作および／または前記デバイスの動作を示すデータを収集すること、ならびに、2)セキュリティを向上させるために前記データを分析することに関係している。例えば、前記データは、前記ネットワークまたはネットワークデバイスに対するアタックを特定し、どのユーザまたはマシーンに責任があるのかを判定するために分析されることができる。前記アタックが継続中である場合、前記アタックを阻止する、または、該アタックによる損害を軽減するための対策が実行可能である。前記収集されるデータは、一般的に、ネットワーク接続されたデバイスによって発生される(イベント、警報もしくは警告等の)メッセージ、または、ログファイルのエントリから生じるものである。典型的なネットワークデバイスは、ファイアウォール、侵入検出システムおよびサーバを含む。
【０００４】
各メッセージまたはログファイル入力(“イベント”)は、将来における使用のために記憶される。記憶されたイベントは、様々な方法で組織化可能である。各組織化法は、それぞれ、イベントデータを書き込むこと、イベントデータをサーチすることおよびイベントデータを削除することに関して利点および不利点を有する。
【０００５】
以下のシナリオについて考察する。各イベントは、イベント受信時間と呼ばれる属性を含む。該イベント受信時間属性の値はサーチのために頻繁に使用されるので、それぞれのイベント受信時間に基づいてイベントを記憶する。例えば、その日の毎分あたり1つのファイルを作成する。イベントを記憶するためには、該イベントのイベント受信時間を決定する。イベント受信時間の該当する分に対応するファイルに前記イベントを付加する。
【０００６】
後のイベントが到来すると、これらのイベント受信時間は、常に、単調に増加することになる。これは、前記後のイベントのデータを書き込むには付加処理のみが必要になることを意味する。記憶媒体を検索する必要はない。これにより、イベントデータの書き込み効率が上昇する。イベント受信時間に基づいてイベントデータをサーチするためには、最初のイベントが特定されたならば、前記媒体を順番に読み取ることによって前記前記後のイベントが入手、利用できる。記憶媒体を検索する必要はない。これにより、イベント受信時間に基づくイベントデータのサーチ効率が上昇する。最も旧いイベントデータを削除するためには、最も旧いファイルが削除される。常に最も旧いファイルが最初に削除される場合、前記記憶媒体の断片化が避けられる。これにより、イベントデータの削除効率が上昇する。
【０００７】
上記の方法の問題点は、イベント受信時間以外の属性に基づくイベントデータのサーチが大変時間のかかるものであるということである。例えば、各イベントが、該イベントを発生したデバイスまたはアプリケーション(“イベントソース”)を示す属性をも含む、と仮定する。前記イベントデータを検索して、特定のイベントソースを示すイベント(例えば、該イベントソース属性についての特定の値を含むイベント)を探し出すためには、前記記憶媒体全体が検査される必要がある。これは、大変非効率的である。
【０００８】
従って、従来より、様々異なるイベントソース属性についてのクエリーをサポートしながら(例えば、多次元インデキシングをサポートすることによって)セキュリティ情報／イベントを効果的に記憶するための方法が必要とされている。
【発明の概要】
【０００９】
ロギングシステムは、異なるイベント属性についてのクエリーをサポートしながらセキュリティ情報／イベントを記憶する。前記ロギングシステムは、セキュリティ情報／イベント管理(SIEM)システムと共に使用されることができる。様々なソース(デバイスおよびアプリケーション)によって生成可能なログデータは、任意のフォーマットであってよい。ログデータは、“イベント”と呼ばれる1または複数のデータインスタンスからなる。イベントは、例えば、ログファイルのエントリ(記録項目)、システムログサーバのエントリ、警報、警告、ネットワークパケット、イーメールまたは通知ページであってよい。一般的に、イベントは、一度だけ発生され、その後は変化しない。
【００１０】
前記ロギングシステムは、イベントレシーバと、記憶マネージャと、通信メカニズムとを含む。前記イベントレシーバはログデータを受信し、ログデータを処理し、データ“チャンク”を出力する。前記イベントレシーバは、制御システムと、バッファのセットと、メタデータ構造体とを有する。前記制御システムは、前記イベントレシーバの動作を制御する。前記バッファのセットは、１または複数のイベントを記憶する。前記メタデータ構造体は、前記バッファのセットの記憶内容についてのメタデータを記憶する。一実施の形態において、前記メタデータは、前記イベントレシーバに関連付けられたユニークな識別子、前記バッファのセット内におけるイベントの数、ならびに、各“対象フィールド”毎に、前記バッファのセットに記憶されたすべてのイベントにわたる前記フィールドの数値範囲を示す最小値および最大値を含む。イベントデータに対してクエリーを行う場合、前記メタデータ構造体は、検索インデックスとして機能する。
【００１１】
前記記憶マネージャは、データチャンクを受信し、クエリーできるよう該データチャンクを記憶する。前記記憶マネージャは、制御システム、データファイルテーブル、チャンクテーブル、および、１または複数のデータファイルを含む。前記制御システムは、前記記憶マネージャの動作を制御する。前記データファイルテーブルは、１または複数のデータファイルについての情報を記憶する。一実施の形態において、前記情報は、各データファイル毎に、前記データファイルに関連付けられたユニークな識別子、および、前記データファイルの位置を含む。前記チャンクテーブルは、前記記憶マネージャに記憶された(特に、１または複数のデータファイルに記憶された)１または複数のチャンクについての情報を記憶する。一実施の形態において、この情報は、各チャンク毎に、該チャンクに記憶されたメタデータ、および、該チャンクの位置を含む。データファイルは多数のチャンクを記憶する。前記通信メカニズムは、前記イベントレシーバと前記記憶マネージャとを通信可能に接続する。
【００１２】
前記イベントレシーバおよび前記記憶マネージャは、共働してログデータを記憶する方法を実行する。前記方法が開始する前に、前記バッファのセットおよび前記メタデータ構造体が初期化される。前記イベントレシーバはログデータを受信する。前記制御システムは、前記ログデータを１または複数のイベントに分け、各イベントデータが前記イベントレシーバによって何時受信されたかを判定する。前記制御システムは、イベント、および、各イベント毎に、該イベントが受信された時を示す時間／日付スタンプを前記バッファのセットに記憶する。前記制御システムは、前記メタデータ構造体をアップデートする。ある時点において、前記制御システムは、前記メタデータ構造体および前記バッファのセット記憶内容に基づいてデータチャンクを発生する。一実施の形態において、チャンクは、前記メタデータ構造体および前記バッファのセットの記憶内容の圧縮されたバージョンを含む。前記バッファおよびメタデータ構造体は再初期化され、これにより前記バッファのセットがフラッシュされる。前記制御システムは、前記記憶マネージャに対してチャンクを送信する。前記記憶マネージャは、前記チャンクを受信し、該チャンクをデータファイルに記憶し、チャンクテーブルをアップデートする。
【００１３】
前記記憶マネージャは、記憶スペースを再生利用するための方法を実行する。特定の保持ポリシーに関連付けられた最も旧いデータファイルが特定される。前記データファイルに含まれたすべてのチャンクに関する情報は、チャンクテーブルから除去される。前記データファイルテーブルにおける前記データファイルを示すエントリ(記録項目)が削除される。新たなエントリが前記データファイルテーブルに作成される。新たに再生されたデータファイルが、利用可能な予め割り当てられたデータファイルのリストに追加され、新たなチャンクを受信可能となる。
【００１４】
チャンクがデータファイルに記憶された後、該チャンク内のイベントに対するクエリーが行われる。クエリーは、イベントに対して評価され得る表現として示される。前記表現は、１または複数の検索語を含む。クエリーを行うために、該クエリーを満足させるイベントを含む可能性があるデータチャンクが特定される。具体的には、前記メタデータ構造体に含まれた情報を含む前記クエリー内の検索語が特定される。前記“メタデータ検索語”を使用して前記チャンクテーブルを検索する。このようにして、前記メタデータに記憶された情報に関する特定の数値に基づいて検索が制約され得る。特定されたチャンクは、それらを構成するイベントに分解される。前記クエリーを満足させるイベントが特定される。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施の形態に従うセキュリティ情報／イベントマネージメントシステムを有する環境を示すブロック図。
【００１６】
【図２】一実施の形態に係るセキュリティ情報／イベント管理システムのロギングシステムとして動作するコンピュータの高レベルブロック図。
【００１７】
【図３】一実施の形態に係るセキュリティ情報／イベント管理システムのロギングシステムを示すブロック図。
【００１８】
【図４】一実施の形態に従ってログデータを記憶する方法を示すフローチャート図。
【００１９】
【図５】一実施の形態に従って記憶装置を再生するための方法を示すフローチャート図。
【００２０】
【図６】一実施の形態に従ってクエリーを行うための方法を示すフローチャート図。
【００２１】
添付図面は例示目的でのみ実施の形態を示している。ここで説明される原理を逸脱することなく、ここで例示する構造および方法の他の実施の形態が採用されてよいことが、以下の説明から当業者に理解されるであろう。
【発明を実施するための形態】
【００２２】
ここに記載されているのは、コンピュータネットワークを介して様々異なるデバイスからデータを収集し、該データを共通のスキーム(構成)に正規化し、該正規化されたデータを統合するためのコンピュータに基づくシステムである。前記データ(“イベント”)は、モニタされ、分析され、ならびに、集中化された観点での調査および修正のために使用されることができる。イベントは、メタイベントを作成するためのルールと相互相関されることができる。相関は、例えば、イベント間の関係を見つけ出し、(例えば、メタイベントを発生することによって)これらの関係の意味を推測し、前記イベントおよびメタイベントを優先順位付けし、さらに、行動を取るためのフレームワークを提供することを含む。前記システム(その一実施の形態はコンピュータソフトウエアとして明白である)は、疑わしきネットワーク活動の集合、補正、検出および調査追跡を可能にする。前記システムは、さらに、裁判分析のための応答管理、その場その場での(アドホックな)クエリー分析、報告および再生、ならびに、ネットワークにおける脅威および活動のグラフィカルな可視化をサポートする。
【００２３】
以下本発明を様々な図示例を参照して説明するが、これらの例は本発明のより広い精神および範囲を制限するものとして解釈されるべきではない。例えば、ここで示される例は分散されたエージェント、マネージャおよびコンソールを説明しているが、これらは本発明の一実施の形態にすぎない。本発明の全体的な概念および範囲は、それよりはるかに広いものであり、いかなるコンピュータに基づくまたはネットワークに基づくセキュリティシステムにも及ぶものである。また、前記システムの構成要素に対して授受され得るメッセージの例、および、前記システムの構成要素によって使用され得る前記データ構成の例が本発明をさらに詳しく説明するために挙げられているが、これらの例は包括的なものではない。
【００２４】
以下の詳細な説明のいくつかの部分は、コンピュータメモリ内のデータについての処理のアルゴリズムおよび記号表現の観点から説明されている。これらのアルゴリズムおよび記号表現は、当業者がかれらの作業内容を他の当業者に最も効果的に伝えるために使用される手段である。ここでは、また一般的には、アルゴリズムは、所望の結果にいたる首尾一貫したステップシーケンスであると考えられている。また、ステップとは、物理的な数量の物理的な操作を必要とするものである。必ずしもそうではないけれど、一般的には、これらの数量は、記憶され、伝送され、組み合わされ、比較されおよびその他の方法で処理されることが可能な電気的または磁気的な信号の形態をとる。主に共通使用可能という理由で、ビット、数値、図形要素、記号、文字、用語、数等としてこれらの信号に言及することが便利になることがある。しかしながら、これらの用語およびこれらに類似した用語のすべては、適当な物理的数量に対応付けられるものであり、これらの数量に適用される単に便利なラベルである。特にそうでないと明記する場合を除き、本発明の説明全体を通じて、"処理"、"計算"、"判定"、“表示”等の用語の使用は、コンピュータシステムのレジスタおよびメモリ内で物理的(電子的)な数量として表現されるデータを処理し、前記コンピュータシステムのメモリもしくはレジスタもしくはその他の情報記憶デバイス、伝送デバイスまたは表示デバイス内で同様に物理的な数量として表現されるデータに変換する動作および処理に言及するものである。
【００２５】
上述の如く、本発明の一実施の形態は、1または複数のコンピュータ／システムによって実現されるときプロセッサ／システムに対して指定された動作を行うよう指令するコンピュータソフトウエア、すなわち、コンピュータによって読み取り可能な命令として説明されている。このようなコンピュータプログラムは、ハードドライブ、CD-ROM、DVD-ROM、読み取り専用メモリ、読み書きメモリ等の1または複数のコンピュータによって読み取り可能に常駐していてよい。このようなソフトウエアは、1または複数の前記媒体に分散されていてもよく、または、1または複数のコンピュータネットワーク(例えばインターネット)を介してダウンロードされるようになっていてもよい。そのフォーマットに関わらず、ここで説明するコンピュータプログラミング、レンダリングおよび処理技術は、単に、本発明の特徴を実現するために使用可能なコンピュータプログラミング、レンダリングおよび処理技術の一例である。これらの例は本発明を制限するものではなく、本発明はこの明細書における発明の説明に続く特許請求の範囲を参照することによって最もよく理解される。
1.  セキュリティ情報／イベントマネージメント(SIEM)システムアーキテクチャ
【００２６】
図1は、本発明の一実施の形態に従うセキュリティ情報／イベントマネージメントシステムを有する環境を示すブロック図である。図1は、セキュリティ情報／イベントマネージメント(SIEM)システム100と、1または複数のデータソース110とを示している。データソース110はネットワークノードであり、デバイスまたはソフトウエアアプリケーションであってよい。典型的なデータソース110は、侵入検出システム(IDS)、侵入阻止システム(IPS)、脆弱性評価ツール、ファイアウォール、アンチウィルスツール、アンチスパムツール、暗号化ツール、アプリケーション検査(audit)ログ、および、物理的セキュリティログを含む。
【００２７】
様々な種類のデータソース110は、セキュリティ検出およびプロキシシステムと、アクセスおよびポリシー制御システムと、コアサービスログおよびログコンソリデータ(consolidator)と、ネットワークハードウエアと、暗号化デバイスと、物理的セキュリティとを含む。典型的なセキュリティ検出およびプロキシシステムは、IDSと、IPSと、多目的セキュリティアプライアンスと、脆弱性評価およびマネージメントと、アンチウィルスと、ハニーポットと、脅威対応技術と、ネットワークモニタリングとを含む。典型的なアクセスおよびポリシー制御システムは、アクセスおよびアイデンティティマネージメントと、仮想プライベートネットワーク(VPN)と、キャッシュエンジンと、ファイアウォールと、セキュリティポリシーマネージメントとを含む。典型的なネットワークハードウエアは、ルータとスイッチとを含む。典型的な暗号化デバイスは、データセキュリティおよびデータ保全性を有する。典型的な物理的セキュリティシステムは、カードキーリーダと、バイオメトリックスと、強盗警報器と、火災警報器とを含む。
【００２８】
図示した実施の形態において、前記SIEMシステム100は、1または複数のエージェント120と、1または複数のマネージャ130と、1または複数のデータベース140と、1または複数のオンラインアーカイブ150と、1または複数のユーザインターフェース160と、1または複数のロギング(logging system)170とを含む。ある実施の形態において、これらのモジュールは、1つのプラットフォームにまとめられ、または、2つ、3つもしくは4つ以上のプラットフォーム(図1参照)に分散される。この多段アーキテクチャを使用することによって、コンピュータネットワークまたはシステムが大きくなるのに伴う拡張性をサポートする。前記SIEMシステム100は、2002年12月2日に出願された米国特許出願No.10／308,415(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。
【００２９】
前記エージェント120は、データソース110に対するインターフェースを提供する。特に、前記エージェント120は、データソース110からデータ(“生イベント”)を収集し、該データを加工し、該加工されたデータ(“イベント”)をマネージャ130に送る。前記エージェント120は、例えば、simple network management protocol(SNMP)トラップのようなプロトコルを介して通信する個別のデバイス、前記ネットワーク内のコンソリデーションポイント、または、データソース110等のどこでも動作可能である。例えば、前記データソース110がソフトウエアアプリケーションである場合、前記エージェント120は、前記データソース110を提供するデバイス上で該データソース110と共に提供され得る。一実施の形態において、前記エージェント120は、カルフォルニア州CupertinoにあるArcSight, Inc.から入手可能なConnector製品である。
【００３０】
前記データの処理は、正規化、集約およびフィルタリングを含むことができる。例えば、個々のデータは、前記マネージャ130による使用のために、解析(パース)され、正規化される。該正規化は、数値(例えば、重大度、優先度および時間帯)を共通のフォーマットに正規化し、および／または、データ構造を共通のデータスキームに正規化することを含んでいてよい。このようなフォーマットにより、ユーザがイベントを理解し、フィルタ、ルールおよびデータモニタを使用して前記イベントを分析するのをより容易にする。一実施の形態において、前記共通のフォーマットは、ArcSight, Inc.から入手可能な共通イベントフォーマット(CEF: Common Event Format)ログ管理規格である。前記正規化については、2002年12月2日に出願された米国特許出願No.10／308,415(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。
【００３１】
前記集約およびフィルタリングは、前記マネージャ130に送られるイベントの量を減少させ、これにより、ネットワーク帯域および記憶スペースを節約し、前記マネージャの効率および精度を向上し、イベント処理時間を減少させる。前記集約については、2002年12月2日に出願された米国特許出願No.10／308,584(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。前記エージェント120は、期間満了に基づいてまたはイベントのしきい数に達したことに基づいて、イベントをバッチ式に前記マネージャ130に送る。前記マネージャ130に送信するイベントのバッチ処理については、2007年5月15日に発行された米国特許No.7,219,239(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。
【００３２】
前記エージェント120は、さらに、コマンドを前記データソース110に送り、および／または、スキャナがスキャンを実行するよう指示するなどのコマンドをローカルホスト上で実行する。これらの動作は、ルールおよびデータモニタに基づいてマニュアルまたは自動的に実行され得る。コマンドサポートについては、2002年12月2日に出願された米国特許出願No.10／308,417(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。前記エージェント120は、さらに、マネージャ130でのIP／ホストネーム検索を解決するためにインターネットプロトコル(IP)アドレスおよび／またはホストネームの検索を行うことなどによって、該エージェント120が収集したデータに情報を付加することができる。
【００３３】
前記エージェント120は、関連したコンフィギュレーション(構成設定)ファイル(図示せず)を介して構成されている。該エージェント120は、正規化要素、時間補正要素、集約要素、バッチ処理要素、レゾルバ要素、移送要素、および／または、追加要素を含む1または複数のソフトウエアモジュールを備えていてよい。これらの要素は、前記コンフィギュレーションファイル中の適当なコマンドを介して起動および／または作動停止されることができる。構成設定時において、前記エージェント120は、マネージャ130に登録され、そのデータソース110および所望の動作に基づく特性で構成設定される。前記エージェント120は、マニュアル処理および自動的な処理の両方によって構成設定される。例えば、前記マネージャ130は、コマンドまたはコンフィギュレーション更新版を前記エージェント120に送ることができる。エージェントの構成要素については、2002年12月2日に出願された米国特許出願No.10／308,548(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。
【００３４】
マネージャ130は、分析機能、ケースマネージメントワークフロー機能およびサービス機能を提供する。前記マネージャ130とエージェント120との通信は、双方向(すなわち、前記マネージャ130が前記エージェント120を主催するプラットフォームにコマンドを送ることを可能にするような形態)であってよく、暗号化され得る。ある設定において、前記マネージャ130は、多数のエージェント120のためのコンセントレーター(concentrator)として動作可能であり、他のマネージャ130(例えば、企業本部で展開されるマネージャ)に情報を送ることができる。そのタスクを実行するために、前記マネージャ130は、様々なフィルタ、ルール、レポート、データモニタ、ダッシユボードおよびネットワークモデルを使用する。一実施の形態において、前記マネージャ130は、ArcSight,inc.から入手可能なEnterprise Security Manager (ESM)製品のようなJava（登録商標）に基づくサーバである。
【００３５】
分析は、検出、相関および拡大を含んでいてよい。例えば、前記マネージャ130は、ルールエンジン(図示せず)を使用して前記エージェント120から受け取ったイベントを相互相関するものであり、該ルールエンジンは、ネットワークモデルおよび脆弱性情報を使用して各イベントを評価することによって、リアルタイム脅威の概要を作成する。相関については、2002年12月2日に出願された米国特許出願No.10／308,767(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。ケースマネージメントに関して、前記マネージャ130はセキュリティインシデントの状況およびその解明に関するレポートを維持することができる。インシデントレペートについては、2003年11月14日に出願された米国特許出願No.10／713,471(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。前記サービスは、管理(administration)、通知および報告を含むことができる。前記マネージャ130は、さらに、知識ベースに対するアクセスを提供することができる。
【００３６】
前記マネージャ130がイベントを受信すると、該イベントはデータベース140に記憶される。該イベントを記憶することにより、後に該イベントを分析し、参照することが可能になる。一実施の形態において、前記データベース140は、カルフォルニア州のRedwood ShoreのOracle Corporationから入手可能なデータベースのようなリレーショナル・データベースである。
【００３７】
一実施の形態において、前記データベース140は、該データベース140の時間的なスライスであるパーティションにデータを記憶する。例えば、1つの新たなパーティションは、毎日その日のイベントを記憶するために作成される。パーティション管理については、2004年5月4日に出願された米国特許出願No.10／839,563(これは、その出典を記載することによって本明細書の一部とする)にさらに詳しく記載されている。一実施の形態において、パーティション管理は、ArcSight, Inc.から入手可能なSecurity Lifecycle Information Management (SLIM)のSmartStorageアーカイブおよび読み出し要素によって実現される。
【００３８】
ユーザは、ユーザインターフェース160を介して前記マネージャ130とインタラクトする。前記ユーザインターフェース160は、ユーザが前記マネージャ130の特徴および機能をナビゲートすることを可能にする。1つのマネージャ130は、多数のユーザインターフェースインスタンスをサポートすることができる。前記ユーザに利用可能な特徴および機能は、該ユーザの役割および許可内容および／または前記マネージャのコンフィギュレーションによって決まる。一実施の形態において、アクセス制御リストは、多数のセキュリティ専門家が同一のマネージャ130およびデータベース140を使用することを可能にするが、各専門家は、彼の責務に適した彼自身の見解、相関ルール、警戒、レポートおよび知識ベースを有する。前記マネージャ130と前記ユーザインターフェース160との間の通信は、双方向で、暗号化可能である。
【００３９】
一実施の形態において、2種類のユーザインターフェース160、すなわち、ワークステーションに基づくインターフェースとウエブブラウザに基づくインターフェースとがある。前記ワークステーションインターフェースは、Security Operations Center (SOC)または同様なセキュリティモニタリング環境におけるフルタイムのセキュリティスタッフによる使用を目的とする標準的なソフトウエアアプリケーションである。前記ワークステーションインターフェースは、フィルタ、ルール、レポート、パターン発見、ダッシュボードおよびデータモニタを作成し、修正するためのオーサリング・ツールを含む。また、前記ワークステーションインターフェースは、ユーザがユーザ、データベースパーティションおよびワークフロー(例えば、インシデント検査および報告)をすることを可能にする。例えば、前記ワークステーションインターフェースは、ユーザが日常的なモニタリングを実行し、複雑な相関および長いシーケントルールを構築し、日常的な管理機能を実行することを可能にする。一実施の形態において、前記ワークステーションインターフェースは、ArcSight, Inc.から入手可能なESM Console製品である。
【００４０】
前記ウェブインターフェースは、ウェブラウザクライアントに対して前記マネージャ130との安全なインターフェースを提供する。前記ウェブインターフェースは、Managed Service Security Providers (MSSP)の顧客、SOCオペレータ、および、前記保護されたネットワークの外部から前記マネージャ130にアクセスする必要があるユーザのための合理化されたインターフェースとして使用されることを目的としている。ウェブサーバは前記マネージャ130から離れた位置に設置可能であるので、前記ウェブサーバは、前記マネージャ130を保護するファイアウォールの外部で動作可能である。前記ウェブインターフェースは、イベントモニタリングおよびドリルダウン機能を提供する。一実施の形態においては、セキュリティ特徴として、前記ウェブインターフェースは、オーサリングまたは管理機能を可能にしない。一実施の形態において、前記ウェブインターフェースは、ArcSight, Inc.から入手可能なArcSight Web製品である。
【００４１】
一実施の形態において、ロギングシステム170は、極めて高いスループットを得るために最適化されるイベントデータ記憶装置である。前記ロギングシステム170は、セキュリティイベント("ログデータ"ともいう)を記憶する。一実施の形態において、セキュリティイベントは圧縮された状態で記憶される。しかしながら、前記ロギングシステム170は、裁判分析的品質のデータを得るためにこれらのデータをオンデマンド(無修正)で読み出すことができる。多数のロギングシステム170が、共働して、イベント記憶時における高い持続的入力速度をサポートできるようスケールアップすることができる。ユーザは、ユーザインターフェース(図示せず)を介して前記ロギングシステム170を構成設定できる。一実施の形態において、前記ロギングシステム170は、ArcSight, Inc.から入手可能なLogger製品である。
【００４２】
前記ロギングシステム170は、加工されたイベント(例えば、Common Event Formatに従うイベント)および生イベントの両方を受信できる。一実施の形態において、生イベントは(システムログメッセージおよびログファイルのような)データソース110から直接に受信され、加工されたイベントはエージェント120またはマネージャ130から受信される。前記ロギングシステム170は、さらに、生イベントおよび加工されたイベントを送ることができる。一実施の形態において、生イベントはシステムログメッセージとして(図示しない任意のデバイス)に送られ、加工されたイベントは前記マネージャ130に送られる。以下、前記ロギングシステム170ついてさらに詳述する。
【００４３】
上記のアーキテクチャにより、前記SIEMシステム100は、集中型または非集中型の環境をサポートすることができる。これは、ある組織がSIEMシステム100の1つのインスタンスを実現し、ユーザをパーティション(区分化)することを欲することがあるからである。あるいは、前記組織は、多数のグループの各々毎に異なるSIEMシステム100を展開し、その結果を“マスターレベル”で確立することがある。このような展開は、また、地理的に分散したピア(peer)グループが、現在通常の勤務時間で働いているグループに主要な監督責任をゆだねることによって、互いに共働する“フォローザサン(follow-the-sun)”構成を実現することができる。SIEMシステム100は、さらに、業務部門が個別に働き集中化された管理機能へのロールアップをサポートする企業内階層に展開可能である。
2.  ログデータ
【００４４】
ここで記載されているのは、クエリーをサポートしながら効率的にログデータを記憶するシステムおよび方法である。ここで“ログデータ”とは、デバイスおよびアプリケーションの両方を含む様々なソースによって発生され得る。これらのソースは、例えば、ネットワークシステムのみならず上記データソース110、コンピュータ、オペレーティングシステム、アンチウィルスシステム、物理的インフラストラクチャ、識別管理システム、ディレクトリサービス、システムヘルス情報システム、ウェブトラフィック、レガシーシステム、プロプライアティシステム、メインフレーム、メインフレームアプリケーション、セキュリティシステム、物理的デバイス、および、(エージェント120およびマネージャ130等の)SIEMソースを含む。
【００４５】
システムは多くの方法でログデータを得ることができる。例えば、ログデータは、(例えば、システムログプロトコルに従って)受信可能である。あるいは、ログデータは、ローカル位置にまたは遠隔位置に記憶されたファイルを読み出すことによって)アクセス可能である。他の方法は、たとえば、Open Database Connectivity (ODBC)、Simple Network Management Protocol (SNMP)トラップ、NetFlow、および、固有のApplication Programming Interface(API)を含む。また、ログデータは、(例えば、コマンドラインインターフェース(CLI)を使用して)ユーザによって入力可能である。
【００４６】
ログデータは任意のフォーマットであってよい。該フォーマットの一例は上記のCommon Event Formatである。他のフォーマットは、たとえば、そのログデータを発生したデータソース110に固有のものである。
【００４７】
ログデータは、“イベント”と呼ばれる1または複数のデータインスタンスからなる。イベントは、例えば、ログファイルのエントリ、システムログサーバのエントリ、警報、警告、ネットワークパケット、イーメールまたは通知ページであってよい。一般的に、イベントは、一度だけ発生され、その後は変化しない。
【００４８】
一実施の形態において、イベントは、黙示的なメタデータおよびメッセージを含む。黙示的なメタデータは、例えば該イベントを発生したデバイスまたはアプリケーション(“イベントソース”)、および、該イベントがイベントソースから受信された時(受信時間)についての情報を含む。一実施の形態において、前記受信時間は日付／時間スタンプであり、前記イベントソースは、ネットワークエンドポイント識別子(例えば、IPアドレスまたはMedia Access Control(MAC)アドレス)、および／または、該製品の販売業者およびバージョンについての情報を含むソースについての記述である。
【００４９】
前記メッセージは、イベントソースから何が受信されたのかを示し、任意の形態(バイナリデータ、英数字データ等)であってよい。一実施の形態において、前記メッセージは、注目すべきシナリオまたは変化を記述する自由形態のテキストである。他の実施の形態において、前記メッセージは、さらに、黙示的なメタデータを含む。黙示的なメタデータは、例えば、前記メッセージを解析することによって得られる。イベントソースがイベントを発生する場合、該イベントは、該イベントが発生した時間(“イベント発生時間”)を示す情報を含む。通常の場合には日付／時間スタンプである該イベント発生時間は、黙示的なメタデータの一例であり、頻繁に分析のために使用される。異なるイベントソースは、しばしば、均一ではない明示的なメタデータ(例えば、イベントの優先度または重要度、イベントによって影響されるデバイス／アプリケーション／ユーザ、ならびに、どのユーザが該イベントを引き起こしたか)を発生する。
【００５０】
一実施の形態において、イベントが発生時間を含まない場合、イベントレシーバが該イベントを受信した時該レシーバによって発生された黙示的なタイムスタンプは、オリジナル発生時間スタンプとして扱われる。イベントが処理され、様々なシステムを介して送られる際、各システムは、通常、イベント受信時間の黙示的な記録を有する。
【００５１】
一実施の形態において、イベントは、各々が数値を含むことができる１または複数のフィールドを含むデータ構造体を示す。このデータ構造体のサイズは、通常100バイトから10キロバイトまでの範囲である。
3.  ロギングシステムアーキテクチャ
【００５２】
図2は、一実施の形態に係るセキュリティ情報／イベント管理(SIEM)システム100のロギングシステム170として動作するコンピュータ200の高レベルブロック図である。図示されているのは、バス204に接続された少なくとも1つのプロセッサ202である。さらにバス204に接続されているのは、メモリ206、記憶装置208、キーパッド208、キーボード210、グラフィックスアダプタ212、ポインティングデバイス214、および、ネットワークアダプタ216である。一実施の形態において、前記バス204の機能は、接続用チップセットによって実現される。ディスプレイ218は、前記グラフィックアダプタ212に接続されている。
【００５３】
前記憶装置208は、ハードドライブ、コンパクトディスク読み取り専用メモリ(CD-ROM)、DVDまたはソリッドステートメモリデバイスなどの、データを保持可能な任意の装置である。前記メモリ206は、前記プロセッサ202によって使用される命令およびデータを保持する。前記ポインティング装置214は、マウス、トラックボールまたはその他のタイプのポインティング装置であり、前記キーボード210と共に使用されて前記コンピュータ200にデータを入力する。前記グラフィックスアダプタ212は、前記表示器218に画像およびその他の情報を表示する。前記ネットワークアダプタ216は、前記コンピュータ200をローカルまたは広域ネットワークに接続する。
【００５４】
当該技術分野で知られているように、コンピュータ200は、図2に示したものとは異なるおよび／またはそれ以外の構成要素を有することができる。さらに、前記コンピュータ200は、図2に示した構成要素のうちのあるものを欠いていてもよい。例えば、ロギングシステム107として機能するコンピュータ200は、キーボード210、ポインティング装置214、グラフィックスアダプタ212、および／または表示器218を欠いていてよい。さらに、前記憶装置208は、ローカルなおよび／または前記コンピュータ200から遠隔のもの(例えば、記憶領域ネットワーク(SAN)内に含まれるもの)であってよい。
【００５５】
図3は、一実施の形態に係るセキュリティ情報／イベント管理(SIEM)システム100のロギングシステム170を示すブロック図である。図示された実施の形態において、前記ロギングシステム170は、イベントレシーバ310、記憶マネージャ320、および、通信メカニズム330を含む。明確さのために1つのイベントレシーバ310のみが示されているが、前記システム170は、多くのイベントレシーバ310との多数の発生セッションをサポートすることができる。一実施の形態において、各イベントレシーバ310はユニークな(固有の)識別子と関連付けられている。
【００５６】
前記イベントレシーバ310は、ログデータ340を受信し、該ログデータ340を処理し、データの“塊(チャンク)”350を出力する。前記イベントレシーバ310は、制御システム355と、１または複数のバッファのセット360と、メタデータ構造体365とを含む。前記制御システム355は、前記１または複数のバッファのセット360およびメタデータ構造体365と通信可能に接続されている。
【００５７】
前記制御システム355は、前記イベントレシーバ310の動作を制御するものであり、図4を参照して以下に説明する。
【００５８】
前記１または複数のバッファのセット360は、１または複数のイベントを記憶する。該１または複数のバッファのセット360は、各イベント毎に、何時イベントレシーバ310によって該イベントが受信されたのかを示す時間／日付スタンプを記憶する。例えば、前記バッファのセット360は、各イベントにこの時間／日付スタンプの値を付加する(これにより、“ReceiptTime(受信時間)”フィールドを付加する)。
【００５９】
前記メタデータ構造体365は、前記バッファのセット360の記憶内容についてのメタデータを記憶する。一実施の形態において、このメタデータは、前記イベントを受信したイベントレシーバ310に関連付けられたユニークな識別子および前記バッファのセット360におけるイベントの数、ならびに、１または複数の“対象フィールド”の各々について、前記バッファのセット360におけるすべてのイベントにわたる前記フィールドの数値範囲を示す最小値および最大値を含む。前記メタデータ構造体365は、イベントデータに対するクエリーを行う(後述)サーチインデックスとして機能する。
【００６０】
例えば、イベントはその数値が該イベントが発生したOccurrence Time(発生時間)と呼ばれるフィールドを含む。Occurrence Timeが対象フィールドである場合、前記メタデータ構造体365は、Occurrence Timeの最小値およびOccurrence Timeの最大値を含む。前記Occurrence Timeの最小値は、前記バッファのセット360における最初に発生したイベントのOccurrence Timeである。また、前記Occurrence Timeの最大値は、前記バッファのセット360における最後に発生したイベントのOccurrence Timeである。
【００６１】
一実施の形態において、ReceiptTimeも対象フィールドである。故に、この実施の形態において、前記メタデータ構造体365は、さらに、前記バッファのセットにおけるすべてのイベントにわたる受信時間の数値範囲を示す最小値および最大値を記憶する。ReceiptTimeの最小値は、前記バッファのセット360における最初に受信されたイベントのReceiptTimeである。また、ReceiptTimeの最大値は、前記バッファのセット360における最後に受信されたイベントのReceiptTimeである。一実施の形態において、ReceiptTimeの最大値は記憶されない。これは記憶要件を減少させる。バッファ360がしばしばフラッシュされる(後述の如く、これはチャンクが発生されたときに起こる)場合、ReceiptTimeの最大値は、ReceiptTimeの最小値に近いものになる(例えば1秒後)。
【００６２】
一実施の形態において、対象フィールドそれ自体はイベントフィールドではない。その代わりに、対象フィールドは、イベントの１または複数のフィールドに記憶された数値に基づいて求められる“派生”値である。
【００６３】
前記記憶マネージャ320は、データチャンク350を受信して、クエリーされ得るよう該データチャンクを記憶する。該記憶マネージャ320は、制御システム370、データファイルテーブル375、チャンクテーブル380、および、１または複数のデータファイル385を含む。前記制御システム370は、データフィールド375、チャンクテーブル380および１または複数のデータファイル385に通信可能に接続される。
【００６４】
前記制御システム370は、前記記憶マネージャ320の動作を制御するものであり、図4を参照して以下に説明する。
【００６５】
前記データファイルテーブル375は、１または複数のデータファイル385についての情報を記憶する。一実施の形態において、データファイルテーブル375における各エントリは、スペースが割り当てられた1つのデータファイル385を示し、該エントリは、前記データファイルに関連付けられたユニークな識別子、および、前記データファイルの位置(例えば、ファイルシステム、該システム内のパス、および、ファイル名)を含む。データファイルテーブル375にリストされたデータファイル385は、(例えば、チャンク350等の)データを含んでいても含んでいなくてもよい。前記データファイルテーブル375は、例えば、(図示しない)データベースに記憶される。一実施の形態において、前記データファイル385は必要とされる前に割り当てられている。この実施の形態において、これらの前もって割り当てられたデータファイル385のリスト(“フリーリスト”という)が維持される。
【００６６】
前記チャンクテーブル380は、前記記憶マネージャ320に記憶された(特に、データファイル385に記憶された)１または複数のチャンク350についての情報を記憶する。一実施の形態において、この情報は、各チャンク350毎に、該チャンクに記憶されたメタデータ(後述)、および、該チャンクの位置(例えば、該チャンクを記憶しているデータファイルに関連付けられたユニークな識別子、および、該チャンクが記憶されたデータファイル内の位置(例えば、オフセットとして))を含む。前記チャンクテーブル380は、例えば、データベース(図示せず)に記憶されている。
【００６７】
データファイル385は多数のチャンク350を記憶する。一実施の形態において、前記データファイル385は、例えば、物理ディスクまたはファイルシステム(図示せず)のようなデータ記憶システムに記憶される。前記データファイル385が物理ディスクに記憶された場合、追加的な回り道が不要なので、データをより高速にアクセス可能になる。さらに、セキュリティが向上する。
【００６８】
前記通信メカニズム330は、前記イベントレシーバ310および記憶マネージャ320を通信可能に接続する。一実施の形態において、前記通信メカニズム330は、インターネットのような部分的に公的または全体的に公的なネットワークを含む。他の実施の形態において、前記通信メカニズム330は、プライベートネットワークまたは１または複数の区別されるまたは論理的なプライベートネットワーク(例えば、仮想プライベートネットワークまたはローカルエリアネットワーク)を含む。前記通信メカニズム330へのおよび前記通信メカニズム330からの通信リンクは、有線または無線(例えば、地上または衛星トランシーバ)であってよい。一実施の形態において、前記通信メカニズム330は、Ethernet（登録商標）プロトコルを使用するIPに基づくワイドまたはメトロポリタンエリアネットワークのようなパケット交換方式のネットワークである。
【００６９】
他の実施の形態において、前記通信メカニズム330は、(前記イベントレシーバ310の一部および前記記憶マネージャ320の一部が同じデバイス上で動作している場合)1つのコンピュータシステムに対してローカルな要素である。この実施の形態において、前記通信メカニズム330は、例えば、ローカルで、ソフトウエアオンリーのループバックデバイスを介して実現される。例えば、データはメモリの様々な位置にコピーされ、通信はAPIを介して行われる。
【００７０】
さらに他の実施の形態において、前記通信メカニズム330は、(前記イベントレシーバ310の一部および前記記憶マネージャ320の一部が同じデバイス上であって同じ処理で動作している場合)1つの処理に対してローカルな要素である。該実施の形態において、前記通信メカニズム330は、例えば、共用メモリおよび／またはポインタを介して実行される。
4.  初期記憶
【００７１】
図4は、本発明の実施の形態に従ってログデータを記憶する方法を示すフローチャート図である。一実施の形態において、図4の方法400は、前記イベントレシーバ310(例えば、その制御システム355)および前記記憶マネージャ320(例えば、その制御システム370)によって実行される。
【００７２】
一実施の形態において、方法400が開始する前に、前記バッファのセット360および前記メタデータ構造体365が初期化される。例えば、前記制御システム355は、前記イベントレシーバ310に関連付けられたユニークな識別子を前記メタデータ構造体365に記憶する。
【００７３】
前記方法400は、前記イベントレシーバ310がログデータ340を受信した(ステップ410)ときに開始する。一実施の形態において、前記ログデータ340は、ストリーム形態で受信される。
【００７４】
前記制御システム355は、前記ログデータを１または複数のイベントに分け(ステップ420)、各イベントデータが前記イベントレシーバ310によって受信された時を決定する(ステップ420)。
【００７５】
前記制御システム355は、イベント、および、各イベント毎に該イベントが受信された時を示す時間／日付スタンプを前記バッファ360に記憶する。前記制御システム355は、さらに、前記メタデータ構造体365をアップデート(更新)する(ステップ430)。例えば、前記バッファ360におけるイベントの数が増加している。対象フィールドの最小値および最大値もアップデートされる必要がある場合がある。一実施の形態において、データ書込み処理およびメタデータ書込み処理は、システムの機能停止が発生した場合の不一致を回避するために同期化される。例えば、イベントが前記バッファ360に記憶されるよう取引データベースシステムが使用され場合、2つのステップ間で内在するシステムの機能停止が発生した場合でも、前記前記メタデータ構造体365がアップデートされることが保証される。
【００７６】
ある時点(後述)において、前記制御システム355は、前記メタデータ構造体365および前記バッファ360の記憶内容に基づいてデータチャンク350を発生する(ステップ440)。一実施の形態において、チャンクは、前記メタデータ構造体365および前記バッファ360の記憶内容の圧縮されたバージョンを含む。前記圧縮されたバージョンは、任意のデータ圧縮アルゴリズム(例えば、GNUジップ(gジップ)によって使用されるもののような可逆圧縮)を使用して発生され得る。バッファ記憶内容を圧縮することによって、当該方法を、長期間のデータ記憶のための費用効率の高い選択とする。一実施の形態において、様々異なるチャンクは様々異なるサイズを有することができ、最大のサイズを指定できる。
【００７７】
一実施の形態において、前記チャンク350は、“マジックナンバ”およびバージョン識別子をも含む。ファイル署名とも呼ばれるマジックナンバは、前記チャンクのデータタイプを特定する短いバイトシーケンスである。例えば、前記マジックナンバは、他のチャンクを含む他のデータおよびファイルフォーマット中で適度にユニーク(すなわち、高い確率でユニーク)である。このようにして、チャンクが読み出される場合、該チャンクが予期されたフォーマットであるか否かを判定するのが容易となる。該チャンクの実際のマジックナンバが予期されたマジックナンバとは異なる場合、該チャンクは“誤”(例えば、破損している)である。該チャンクの実際のマジックナンバが予期されたマジックナンバと一致する場合、該チャンクにおいて後に発生するデータは依然として誤であるかもしれない。しかしながら、前記一致するマジックナンバは、通常の状況のうちの大多数についてこのような可能性を排除する。前記バージョン識別子は、変化したデータおよびファイルフォーマットの適応を可能にする。例えば、チャンクが読み出されるとき、前記バージョン識別子は、前記データおよびファイルフォーマットについての付加的な情報を示すために、前記マジックナンバと共に使用される。
【００７８】
他の実施の形態(これも図示せず)において、前記制御システム355は、前記バッファ360の記憶内容のメッセージダイジェストをも発生する。例えば、前記制御システム355は、前記バッファ360の記憶内容を示す文字列に暗号学的ハッシュを適用する。Message-Digestアルゴリズム5(MD5)またはSecure Hash Algorithm ファミリーのアルゴリズム(例えば、SHA-256)等の任意の暗号学的ハッシュを使用してよい。一実施の形態において、前記ダイジェストの値は、該チャンクが作成される前に前記メタデータ構造体365に記憶される。この値は、前記チャンクに(圧縮された状態で)に記憶されているバッファデータが変更されまたは改ざんされているか否かを判定する。これは、該イベントが変更された時を顕著にすることによって、記憶されたイベントの完全性を保証する。
【００７９】
そして、前記バッファ360およびメタデータ構造体365は再初期化され(ステップ440)、これにより前記バッファ360がフラッシュされる。一実施の形態において、前記バッファのセット360は多数のバッファを含む。この実施の形態により、1つのバッファが満杯またはフラッシュされている間、他のバッファが入力されるイベントを記憶するために使用される。
【００８０】
一実施の形態において、ステップ440は、バッファが満杯のときに実行される。他の実施の形態において、ステップ440は特定の期間(“タイムアウトウィンドウ”)が経過したとき実行され、その間前記バッファ360によってイベントの受信はなされない。
【００８１】
前記制御システム355は、前記記憶マネージャ320にデータチャンク350を送る(ステップ450)。
【００８２】
前記記憶マネージャ320は、チャンク350を受信する(ステップ460)。前記制御システム370は、該チャンクをデータファイル385に記憶する(ステップ470)。一実施の形態において、前記チャンクは、セキュリティ目的で、記憶される前に暗号化される。また、前記制御システム370は、前記チャンクテーブル380をアップデートする(ステップ470)。例えば、前記制御システム370は、前記データファイル385に記憶して前記チャンク350に関する情報を前記テーブルに追加する。
【００８３】
前記制御システム370は、各データファイル385内にチャンク350を“付加順”に書き込む。これは、“追記型ジャーナル”と呼ばれることがある。一実施の形態において、前記制御システムは、チャンクが書き込み可能なデータファイル内の位置を示す“書き込みポインタ”を維持する。チャンクがデータファイルに書き込まれた後、前記書き込みポインタは、同一のデータファイル内の他の位置(特に、書き込まれた前記チャンクの終り)を示すよう変更される。チャンクを書き込むことによってデータファイルが一杯になると、前記書き込みポインタは、他のデータファイル内の位置(特に、始め)を示すよう変更される。一実施の形態において、チャンクの書き込みはメモリ内に最初にチャンクをキャッシュすることによって遅延される。その後、RAID5ディスク記憶システムにおけるフルストライプ書き込みを最適化するために、多数の連続したチャンクが1つの書き込み処理に組み合わされる。書き込み等の大規模なシーケンシャルな入力処理を使用することによって、ハードウエアは高速、高スループットおよび同時並行性で駆動される。
【００８４】
(例えば、上記のフリーリストにリストされたような)予め割り当てられたデータファイルが存在する場合、前記制御システム370は、前記データファイルを使用し、前記フリーリストから該データファイルのユニークな識別子を除去する(該データファイルはもはや利用可能ではないので)。予め割り当てられたデータファイルが存在しない場合、前記制御システム370は、利用可能なスペースを探し出し、前記データファイルテーブル375をアップデートすることによって新たなデータファイルを作成する。例えば、前記制御システム370は、それが作成した新たなデータファイル385に関する情報を前記テーブルに追加する。一実施の形態において、前記新たなデータファイル385に割り当てられたユニークな識別子は、最も最近割り当てられたデータファイル385のユニークな識別子に1を加算した和に等しい。
【００８５】
前記方法400は、多くの望ましい特徴を有する。例えば、該方法は、極めて高い毎秒あたりイベント数(EPS)の受信をサポートできるので、拡張性が高い。多数のイベントレシーバ310を使用可能であり、該方法は検索処理を必要とせず付加処理のみを必要とする。該方法はデータに対する連続的なアクセスを実現するので、該方法400は利用可能性が高い。旧いイベントを削除しても記録媒体を断片化しないので、デフラグ(defragmentation)処理が不要であり、従って、メインテナンスウィンドウも不要である。クリーンアップタスクための黙示的なダウンタイム(休止時間)が不要である。さらに、ディスク書き込み処理を効率的に行うことができるので、クエリーを処理するための余裕を空けるためのオーバーヘッドを回避する。
5.  記憶スペース再生
【００８６】
ある時点(後述)において、１または複数のデータファイル385によって使用されている記憶スペースを将来の使用のために再生(利用)させられる。図5は、本発明の一実施の形態に従って記憶スペースを再生するための方法を示すフローチャート図である。一実施の形態において、図5の方法500は、記憶マネージャ320(例えば、その制御装置370)によって実行される。
【００８７】
特定の保持ポリシー(後述)に関連付けられた最も旧いデータファイル385が特定される(ステップ510)。データファイルは単純に増加する数に基づくユニークな識別子を有するので、データファイルテーブル375にクエリーを行って、保持ポリシーに関連付けられた最も旧いデータファイル(すなわち、最も低いユニークな識別子を有するデータファイル)を見つけるのは容易である。
【００８８】
前記データファイル385に含まれたすべてのチャンク350に関する情報は、チャンクテーブル380から除去される(ステップ520)。
【００８９】
前記データファイルテーブル375における前記データファイル385を示すエントリが削除される(ステップ530)。
【００９０】
a)  最も高い使用済みデータファイル識別子より1だけ高い新たなユニークな識別子およびb)  以前最も旧かったデータファイル(すなわち、ステップ510で特定されたデータファイル)の物理的位置に言及するパス属性を使用して、データファイルテーブル375に新たなエントリを作成する(ステップ540)。
【００９１】
新たに再生されるデータファイル385が、利用可能な予め割り当てられたデータファイルのリストに追加され(ステップ550)、新たなチャンクを受信可能となる。
【００９２】
図示した実施の形態において、データファイルの記憶スペースが再生されると、該データファイルは、削除される代わりに、リサイクル(例えば、再使用または上書き)される。
【００９３】
記憶スペース再生アルゴリズム(例えば、その実行時および記憶スペース再生量)を含む記憶スペース再生アルゴリズムの詳細は、データファイル385に関連付けられた保持ポリシーに依存する。保持ポリシーは、例えばディスクスペース使用しきい値またはチャンク350を保持する最大時間に基づいて、前記チャンク350の保持を制限する。記憶スペース再生アルゴリズムを実行するときの例としては、前記ポリシーに関連付けられたすべてのデータファイルが満杯で、更なるデータファイルが割り当てできないとき(例えば、記憶スペースが残っていないという理由により);  特定のしきい値に達したとき(例えば、前記ポリシーに関連付けられたデータファイルに残されているフリー記憶スペースの量に関して);  特定の期間が経過したとき;  前記ポリシーに関連付けられた特定の数のデータファイルが存在するとき;  前記ポリシーに関連付けられたデータファイルにおける最も旧いチャンクがしきい年齢に達したとき、がある。一実施の形態において、データファイルは、そのスペースが再生される前に、その他のシステムにバックアップされる。このようにして、既存のデータを維持しながら、更なる記憶スペースが利用可能になる。
【００９４】
一実施の形態において、すべてのデータファイル385が同一の保持ポリシーに関連付けられる。他の実施の形態においては、多数の保持ポリシーが存在し、各データファイルは、前記多数の保持ポリシーのうちのいずれか1つに関連付けられ得る。多数のデータファイルが同一の保持ポリシーに関連付けられ得る。保持ポリシーは、ユーザによって作成され、修正され得る。一実施の形態において、前記記憶マネージャ320は、各保持ポリシー毎に上述した記憶スペース再生アルゴリズムの1つのインスタンスを論理的に維持する。例えば、各データファイル385は、該データファイルに適用される保持ポリシーを示すメタデータを含み、チャンクは、そのチャンクの保持ポリシーに対応するデータファイルに記憶される。
【００９５】
多数の保持ポリシーが存在する場合、図3に示した前記システム170は、幾分変更される(図示せず)。特に、前記イベントレシーバ310は、各保持ポリシー毎に、1つのバッファのセット360と、1つのメタデータ構造体365とを有する。イベントが前記バッファのセットに記憶され、前記メタデータ構造体がアップデートされる(ステップ430)、前記制御システム355は、該イベントにどの保持ポリシーが適用されるべきかを判定する。この判定は、特定のイベントの属性または静的なマッピングに基づく。優先度またはイベントソースのような属性が使用され得る。この判定に基づき、前記制御システム355は、前記イベントを適当なバッファのセットに記憶し、適当なメタデータ構造体をアップデートする。このようにして、特定のバッファのセットにおけるすべてのイベントが同一の保持ポリシーに関連付けられる。
【００９６】
すなわち、前記バッファのセットに基づいて発生したチャンク350が同一の保持ポリシーに関連付けられるということになる。前記チャンクがデータファイル385が記憶される(ステップ470)前に、前記制御システム370は、前記チャンクの保持ポリシーを決定し、該チャンクを前記ポリシーに関連付けられたデータファイルに記憶する。このようにして、特定のデータファイルにおけるすべてのチャンクが同一の保持ポリシーに関連付けられることになる。
【００９７】
一実施の形態において、各保持ポリシーは、それ自身のデータファイル385のグループを有する。各データファイルには、ユニークな識別番号が付加される。該番号は、1つのグループ内におけるファイルの順序を決定する。前記データファイルは、付加された順序で書き込まれる。ファイルはアップデートされず、一度書きされ、付加のみのモードで操作され、これにより、ログデータの改ざんが阻止される。1つの保持ポリシー内のすべてのファイルが満杯になると、そのグループ内の最初の(すなわち、最も旧い)ファイルから記憶スペースが再生される。一実施の形態において、各保持ポリシー毎に異なるデータファイルテーブル373が維持され、該テーブル373は、前記保持ポリシーに割り当てられたデータファイル385のエントリを含む。フリーリストが維持される場合、いくつの保持ポリシーが存在するのかに関わらず、ただ1つの保持ポリシーのみが前記記憶マネージャ320のために使用される。
6.  クエリーおよびデータ読み出し
【００９８】
チャンク350がデータファイル385に記憶された後、該チャンク内のイベントに対するクエリーが行われる。クエリーは、イベントに対して評価され得る表現として示される。前記表現は、１または複数の検索語を含む。一実施の形態において、クエリー処理は、多段階に行われる。第1の段階は、どのデータチャンク(もし有れば)が前記クエリーを満足させるイベントを含むのかを判定する。第2の段階は、前記見つけられたチャンクを連続したイベントに分解する。第3の段階は、これらのイベント(もし有れば)のどれが前記クエリーを満足させるかを判定する。これにより、第1の段階は、どのデータチャンク(およびそれらのイベント)がさらに調べられるべきか、および、どのデータチャンク(およびそれらのイベント)が無視されるべきかを判定するための“粗つなぎ”として作用する。ほとんどの場合、どの保持ポリシーがイベントを含むチャンクに適用されているのかは興味のある問題ではないので、イベントがクエリーされまたは読み出されるとき、チャンクに割り当てられた保持ポリシーは考慮されない。
【００９９】
前記第1の段階において、(前記イベントがデータファイル385におけるデータチャンク350の一部としてというよりも、前記バッファ360にイベントとして記憶された際)前記メタデータ構造体365に含まれた情報に関する前記クエリー内の検索語が特定される。このメタデータ情報は、関連付けられたイベントレシーバのユニークな識別子を含み、各対象フィールド毎に、多数のイベント(初期的には、同一バッファにおけるイベント、後には、同一のデータチャンク内のイベント)に亘る前記フィールドの数値範囲を示す最小値および最大値を含む。上述の如く、前記メタデータ情報は、チャンク150の一部として前記記憶マネージャ320に送信される。その後、前記メタデータ情報は、チャンクテーブル380に記憶される。従って、このメタデータに基づいて前記イベントを検索するために、前記“メタデータ検索語”を使用して前記チャンクテーブル380を検索する。これは、どのチャンク(もし有れば)が前記メタデータ検索語を満足させるイベントを含むのかを確認する。このようにして、(これらの値が前記チャンクテーブル380におけるメタデータに記憶されているので)イベントレシーバおよび／または対象フィールドに関する特定の数値(または数値範囲)に基づいて検索が制約され得る。
【０１００】
“対象フィールド”メタデータは数値範囲として表現されているので、チャンクがメタデータ検索語を満足させるという事実は、前記チャンクが前記メタデータ検索語を満足させるイベントを含むということを必ずしも意味しない。例えば、前記メタデータ検索語が10というフィールドの値であり、前記チャンクがそのフィールドの値が5および15であるイベントを含む場合、10が前記範囲内となり、前記チャンクは前記メタデータ検索語を満足させると判定されることになる。しかしながら、前記チャンクは10というフィールドの値を持つイベントを含まないかもしれない。(これは前記クエリーが2段階で発生する理由である。)しかしながら、チャンクが前記検索語を満足させたイベントを含む場合、該チャンクが前記検索語を満足させるものであると確認されることになる。
【０１０１】
第2の段階において、前記確認されたチャンクはそれらを構成するイベントに分解される。チャンクのイベント部分が該イベントの圧縮バージョンを含む場合、該イベント部分は、それらを構成するイベントに分解される前に解凍される。
【０１０２】
第3の段階において、前記イベントが前記検索語を満足させるものか否かを判定するために、各イベントが完全な検索語セットと比較される。例えば、前記イベントは、それらの受信時間に基づいて分析される。前記イベントを特定の順序で分析し、検索結果に一致イベントを付加することは、前記検索結果における前記イベントが常に前記特定の順序であることを意味する。前記イベントのソート(sort)は必要ではない。
【０１０３】
第1の段階において、前記検索語のどれも前記メタデータ構造体365に含まれた情報に関するものではない可能性がある。この場合、(メタデータ検索語が存在しないので)すべてのチャンク350が、メタデータ検索語を満足させるイベントを含むと判定されることになる。これにより、前記クエリー処理は、前記メタデータ検索語のすべてを使用して各記憶されたイベントを単純にサーチするよう退化する。これは、上述した素朴で、非効率的な組織的方法に似ている。
【０１０４】
上記アルゴリズムは、チャンク350に記憶されたイベントを検索する。しかしながら、前記ロギンクシステム170は、チャンクに記憶されなかった追加的なイベントを前記イベントレシーバ310内(例えば、バッファのセット360)に含んでいることがある。上述したアルゴリズムはこれらのイベントを検索しない。一実施の形態において、前記アルゴリズムが実行される前に、前記イベントが前記記憶マネージャ320に送信されてチャンクに記憶されるよう、前記バッファのセット360がフラッシュされる。このようにして、前記アルゴリズムが実行される際、前に前記バッファのセット360にあったイベントも検索されることになる。他の実施の形態において、上述したアルゴリズムと同様な前記メタデータ構造体365およびバッファのセット360の記憶内容を使用して、前記イベントレシーバ310について異なる検索が実行される。このようにして、すべてのイベントについて、それらのイベントが前記記憶マネージャ320に記憶されているのかまたは前記イベントレシーバ310に記憶されているのかに関わらず、すべてのイベントが検索されることになる。
【０１０５】
図6は、本発明の実施の形態に従ってクエリーを行う方法を示すフローチャート図である。一実施の形態において、図6の方法600は、前記記憶マネージャ320(例えば、その制御システム370)によって実行される。前記方法600が開始される前に、検索クエリーが受信される。該検索クエリーは、１または複数の検索語を含む。
【０１０６】
(受信された検索クエリー内の)メタデータ検索語が特定される(ステップ610)。
【０１０７】
特定された前記メタデータ検索語を使用して、前記チャンクテーブル380が検索される(ステップ620)。上述の如く、前記チャンクテーブル380における各エントリはチャンク350に対応し、該エントリは、前記チャンクに記憶されたメタデータと、該チャンクの位置を含む。また、前記特定されたメタデータ検索語を使用して、前記チャンクテーブル380のメタデータ部分を検索する。
【０１０８】
そのメタデータが前記メタデータ検索語を満足させる各チャンク350が、前記チャンクテーブル380における記憶位置を使用して読み出される(ステップ630)。
【０１０９】
読み出された前記チャンクがそれらを構成するイベントに分解される(ステップ640)。
【０１１０】
前記イベントが前記クエリーを満足させるか否かを判定するために、各イベントが前記検索クエリーに対して評価される(ステップ650)。
7.  その他の実施の形態
【０１１１】
一実施の形態において、前記ロギングシステム170は、データファイル385の機能を保存することをサポートする。例えば、データファイル385は、前記ロギングシステム170にインポートされ、前記ロギングシステム170からエクスポートされ得る。その他の例として、データファイル385は、他のシステムにバックアップされ、その後、前記ロギングシステム170に復元されることができる。イベントはチャンクに記憶され、チャンクはデータファイルに記憶されるので、イベントは容易にニアラインまたはオンライン記憶装置に伝送可能である。アーカイバル規準は、クエリーに使用される規準(例えば、メタデータ構造体に記憶された情報の値)に類似している。
【０１１２】
以上本発明の好ましい実施の形態の動作について説明したが、ここでの説明は本発明の範囲を制限するものではない。本発明は、次の特許請求の範囲によってのみ限定されるものである。上記の説明から、本発明の精神および範囲に包含される多くの変更が可能であることが当業者に明らかであろう。
【図１】
2010515172.tif 000003
【図２】
2010515172.tif 000004
【図３】
2010515172.tif 000005
【図４】
2010515172.tif 000006
【図５】
2010515172.tif 000007
【図６】
2010515172.tif 000008
【国際調査報告】
2010515172.tif 000009