JP2015502060A - ネットワークメタデータを処理するストリーミング方法およびシステム - Google Patents

Abstract

ネットワークメタデータを処理するための方法およびシステムについて記述する。ネットワークメタデータは、ネットワークメタデータの特徴について、かつネットワークメタデータにより伝送される情報のコンシューマへのネットワークメタデータの提示についてポリシベースの決定を下す動的にインスタンス化される実行可能ソフトウェアモジュールによって処理されてもよい。ネットワークメタデータは、タイプ別に分類されてもよく、かつタイプ内の各サブクラスは、一意のフィンガープリント値によって定義へマップされてもよい。フィンガープリント値は、ネットワークメタデータのサブクラスを関連するポリシおよび変換規則に照らしてマッチングするために使用されてもよい。ＮｅｔＦｌｏｗ ｖ９等のテンプレートベースのネットワークメタデータの場合、本発明の一実施形態は、未知のテンプレートを探してネットワークトラフィックを絶えず監視し、テンプレート定義を捕捉し、かつカスタムポリシおよび変換規則が存在しないテンプレートについて管理者に知らせることができる。変換モジュールは、ネットワークメタデータの選択されたタイプおよび／またはサブクラスを代替メタデータフォーマットへ効率的に変換することができる。【選択図】 図３

Description

概して、本発明は、ネットワークの監視およびイベント管理に関する。より具体的には、本発明は、ネットワークの監視アクティビティを介して入手されるネットワークメタデータの処理、およびこれに続くメタデータの処理に関し、これにより、メタデータのコンシューマには有益な情報が効率よくタイムリーに伝わることになる。

ネットワーク監視は、企業およびサービスプロバイダによってしばしば使用される極めて重要な情報技術（ＩＴ）であって、パフォーマンス、不正行為をするホスト、不審なユーザアクティビティ、他に関連する問題点について、内部ネットワーク上で発生するアクティビティを見張ることを含む。ネットワーク監視は、様々なネットワークデバイスにより提供される情報によって可能にされる。この情報はこれまで、概してネットワークメタデータと称され、即ち、ネットワーク上で伝送される他の情報を補足しかつ相補するものであるネットワーク上のアクティビティを記述する情報クラスを指している。

Ｓｙｓｌｏｇは、ネットワーク監視に一般的に使用されるネットワークメタデータの一タイプである。Ｓｙｓｌｏｇは、プログラムメッセージをログするための規格であって、他では管理者に問題またはパフォーマンスを知らせる手段を伝達することができないデバイスを提供する。Ｓｙｓｌｏｇは、コンピュータシステムの管理およびセキュリティ監査、ならびに一般化された情報、分析およびデバッグメッセージ用に使用されることが多い。これは、複数のプラットフォームに渡る（プリンタおよびルータのような）広範なデバイスおよび受信機によってサポートされている。これに起因して、Ｓｙｓｌｏｇは、多くの異なるタイプのシステムからのログデータを中央リポジトリに統合するために使用されることが可能である。

さらに最近では、様々なベンダーによりＮｅｔＦｌｏｗ、ｊＦｌｏｗ、ｓＦｌｏｗ、他と称される別のタイプのネットワークメタデータも、規格ネットワークトラフィックの一部として導入されている（以後、概して「ＮｅｔＦｌｏｗ」と称する）。ＮｅｔＦｌｏｗは、トラフィック監視用の業界標準となっている、ＩＰトラフィック情報を収集するためのネットワークプロトコルである。ＮｅｔＦｌｏｗは、ルータ、スイッチ、ファイアウォール、侵入検知システム（ＩＤＳ）、侵入防止システム（ＩＰＳ）、ネットワークアドレス変換（ＮＡＴ）エンティティ、他多数等の様々なネットワークデバイスによって生成されることが可能である。しかしながら、最近まで、ＮｅｔＦｌｏｗのネットワークメタデータは、専ら、ネットワークトポロジーの発見、ネットワークスループットのボトルネックのロケーティング、サービス水準合意（ＳＬＡ）の検証、他等の事後のネットワーク監督を目的として使用されている。ＮｅｔＦｌｏｗメタデータのこのような限定的使用は、概して、ネットワークデバイスにより生成される情報の多量さおよび高い送出量、情報ソースの多様さ、および追加的な情報ストリームを既存のイベントアナライザへ統合する全体的な複雑さに起因する可能性がある。より具体的には、ＮｅｔＦｌｏｗメタデータの生成者は、典型的には、コンシューマがリアルタイム設定で分析しかつ使用し得る量より多い情報を生成している。例えば、ネットワーク上の大規模スイッチへの単一媒体は、１秒当たり４００，０００個のＮｅｔＦｌｏｗレコードを生成する場合もある。

今日のｓｙｓｌｏｇコレクタ、ｓｙｓｌｏｇアナライザ、セキュリティ情報管理（ＳＩＭ）システム、セキュリティイベント管理（ＳＥＭ）システム、セキュリティ情報およびイベント管理（ＳＩＥＭ）システム、他（以後、纏めて「ＳＩＥＭシステム」と称する）は、ＮｅｔＦｌｏｗの受信分析ができず、ＮｅｔＦｌｏｗパケットに含まれる初歩的な情報の処理に限定されるか、ＮｅｔＦｌｏｗパケットを、このようなパケットが典型的に生成される速度より遙かに低い速度で処理するか、の何れかである。

ＮｅｔＦｌｏｗ ｖ９（ＲＦＣ３９５４）およびＩＰＦＩＸ（ＲＦＣ５１０１および関連のＩＥＴＦ ＲＦＣ）等のロバストなネットワーク監視プロトコルは、ネットワークセキュリティおよびインテリジェントネットワーク管理の領域においてネットワークメタデータを用いる機会を大幅に拡大している。同時に、先に同定した制約に起因して、今日のＳＩＥＭシステムは、概して、単に観察されたバイトおよびパケット計数を報告するだけで、ネットワーク監視情報を利用することはできない。

ネットワークマネージャおよびネットワークセキュリティの専門家は、業界で「ビッグデータ」と称される問題に絶えず直面し、かつ闘っている。ビッグデータ問題により生じる問題点の中には、異なるフォーマットおよび構造で存在することが多い膨大な量の機械生成データを分析かつ記憶できないことが含まれる。一般的に遭遇する課題は、下記のように要約することができる。

１．リアルタイムで分析するにはデータが多すぎて、ネットワーク状態に関する時宜を得た識見を得ることができない。

２．データがネットワーク上の異なるデバイスタイプから異なるフォーマットで到来し、異なるデバイスタイプからのデータ補正を困難かつ遅くする。

３．データが多すぎて、（例えば、後の分析用および／またはデータ保持要件との整合用に）記憶することができない。

本発明は、大量のメタデータをリアルタイムで分析し、大量のメタデータを、単一の監視システム内部の他のデータによる即時的相関を可能にする共通フォーマットへ変換する能力を提供し、かつパケット検証、フィルタリング、集約および重複排除等のリアルタイムデータ低減技術を介して着信データ量を大幅に低減することにより、ビッグデータに関連づけられる先に同定した全ての課題に対処することができるシステムおよび方法を提供する。

本発明の実施形態は、着信するネットワークメタデータ・パケットの有効性をチェックして、不正な形式の、または不適切なメッセージを廃棄することができる。また実施形態は、着信するネットワークメタデータのパケットを、その情報コンテンツの関連態様を識別するためにリアルタイムで調べかつフィルタリングし、かつ着信するネットワークメタデータの異なるストリームを、本発明の処理エンジン内で異なった処理をするためにセグメント化またはルーティングすることもできる。このような異なる処理には、ネットワークマネージャにより構成される、および、着信メッセージの早期調査の間に決定されることが可能な基準を基礎として特定のメッセージまたは選択されるメッセージストリームをドロップすることによって出力メタデータのトラフィックを低減する機会が含まれる。これにより、ネットワークマネージャは、ネットワーク分析を、持続ベースまたは特定のネットワーク状態に応答する一時的なものの何れかに集中させることができる。一例として、ネットワークマネージャは、侵入イベントの可能性を調査するために、ネットワーク上のエッジデバイスとなるべく限定して生成されるシステム内部のネットワークメタデータに注目するように選ぶことができる。

本発明の実施形態は、さらに、着信するネットワークメタデータ・パケットに含まれる情報コンテンツを集め、かつ大量の関連パケットを、同じ情報を捕捉するが、生成するダウンストリームディスプレイ、分析および記憶要件がオリジナルのメタデータフローより遙かに少ない１つのパケット、または遙かに少数の他のパケットと置換することができる。

本発明の実施形態は、さらに、ネットワークデバイスにより生成される正常なメタデータフローのコンテンツの重複を排除することができる。着信トラフィックは、典型的には、ネットワーク内で一連のネットワークデバイスを介して宛先デバイスへとルーティングされることから、また、各ネットワークデバイスは、典型的には、各ネットワークデバイスを横断するフロー毎にネットワークメタデータを生成することから、大量の余分なメタデータが生成され、業界のビッグデータ問題を引き起こす。

本発明は、例えばネットワークまたは機械生成メタデータである、様々なデータフォーマットの任意の構成データ（以後、ネットワークメタデータ）を受信し、ネットワークメタデータを効率的に処理し、かつ受信されるネットワークメタデータおよび／またはオリジナルのネットワークメタデータから導出されるネットワークメタデータを様々なデータフォーマットで転送することができるシステムおよび方法に関する。ネットワークメタデータは、ルータ、スイッチ、ファイアウォール、侵入検知システム（ＩＤＳ）、侵入防止システム（ＩＰＳ）、ネットワークアドレス変換（ＮＡＴ）エンティティ、他多数等の様々なネットワークデバイスによって生成される可能性もある。
ネットワークメタデータの情報は、ＮｅｔＦｌｏｗおよびその変形（例えば、ｊＦｌｏｗ、ｃｆｌｏｗｄ、ｓＦｌｏｗ、ＩＰＦＩＸ）、ＳＮＭＰ、ＳＭＴＰ、ｓｙｓｌｏｇ、他を含む、但しこれらに限定されない幾つかのフォーマットで生成される。本明細書に記述する方法およびシステムは、ネットワークメタデータの情報を、ＮｅｔＦｌｏｗおよびその変形（ｊＦｌｏｗ、ｃｆｌｏｗｄ、ｓＦｌｏｗ、ＩＰＦＩＸ）、ＳＮＭＰ、ＳＭＴＰ、ｓｙｓｌｏｇ、ＯｐｅｎＦｌｏｗ、他を含む、但しこれらに限定されない幾つかのフォーマットで出力することができる。さらに、本発明の実施形態は、選択されたタイプのネットワークメタデータ情報を、リアルタイムまたはリアルタイムに近いネットワークサービスの提供を可能にするに足る速度で出力することができる。その結果、本システムは、Ｎ（Ｎ≧１）名のネットワークメタデータ生成者およびＭ（Ｍ≧１）名のオリジナルまたは導出されたネットワークメタデータのコンシューマによる配備において、有意義なサービスを提供することができる。本発明の特定の一実施形態が、ＲＦＣ５９８２に反映されているようなＩＰＦＩＸメディエータの定義に整合することは認識され得る。

本発明の一実施形態は、受信されるネットワークメタデータの性質、特徴および／またはタイプ（「クラス」）を識別し、かつ受信される情報をカテゴリまたはクラスに編成するための方法およびシステムを提供する。これは、テンプレートを基礎としかつコンテンツおよび目的が広範であることが可能なＮｅｔＦｌｏｗ ｖ９およびこれに類似するメッセージに関連して使用される場合に特に有益であり得る。一旦カテゴリまたはクラスに編成されると、個々のクラス・メンバ・インスタンスは、さらに、ゼロの、１つの、または複数のクラス指定処理規則に従って、またはデフォルトの処理規則（「ポリシ」）に従って処理されることが可能である。本発明のこの態様は、限りなく広範なタイプのネットワークメタデータをきめ細かく処理することができる。

着信ネットワークメタデータのクラスをオペレーションの早期段階で識別することにより、この実施形態は、ネットワークメタデータの処理を効率的に編成することができ、かつ適切な状況において、システム管理者にとっての限定的な興味の対象であるネットワークメタデータ部分をフィルタリングし、統合しかつ／または排除して必要な処理量を低減することができ、これにより、システムのリアルタイムまたはリアルタイムに近いオペレーションに貢献し、かつネットワークメタデータのコレクタ（収集器）側の記憶要件を低減する。例えば、ある特定のネットワークトラフィック本体がネットワーク内の複数のデバイス（装置）をトラバースするにつれて、冗長な情報を含むトラバースされた各デバイスからネットワークメタデータが生成されてもよい。ＳＩＥＭシステム内部に画定される監視の焦点またはエリアに依存して、ＳＩＥＭシステムへ転送されるメタデータフローから、冗長な情報を含むメタデータレコードをフィルタリングし、集め、統合し、または排除することが望ましい場合がある。ＳＩＥＭシステムへ方向づけられる所定のクラスのネットワークメタデータから冗長性を除去し、同時にコレクタへ方向づけられるフローのメタデータを全て保全するポリシの導入が可能である。

したがって、本発明の実施形態により実装されるポリシが、ＳＩＥＭシステムの焦点であるポリシまたはエリア、および／またはネットワーク内部で動作するメタデータコレクタをサポートしかつ／またはこれと調和されるように定義可能であることは認識されるであろう。

ポリシは、ネットワーク管理およびセキュリティを目的として、セキュリティ攻撃を示す可能性もある重要な、または珍しいネットワークイベントを検出し、ネットワーク上のトラフィックスパイクを報告し、ネットワークへの攻撃を検出し、ネットワークリソースのより良い使用法を育み、かつ／またはネットワーク上で実行されるアプリケーションを識別するために導入されることが可能である。ポリシは、汎用である可能性も、時間ベースである可能性もあり、かつネットワークを通過する特定クラスのネットワークメタデータ、またはネットワークメタデータのサブセットに適用されることが可能である。本発明の一実施形態は、システムのスループットおよびパフォーマンスを向上させるために、複数のポリシモジュールと共動する複数のワーキングスレッドの準備を企図している。

ワーキングスレッドは、システムのパフォーマンスおよびスループットをさらに拡大するために特定のクラスまたはサブクラスのネットワークメタデータと共用するように特化または調整されたものを導入することができる。このような特化されたワーキングスレッドおよびポリシモジュールは、システムのパフォーマンスおよびスループットを拡大するために、ネットワークメタデータ・ストリームの異なる部分に処理オペレーションを並行して実行することができる。また、システムのパフォーマンスおよびスループットをさらに拡大するために、かなりの量の特定のクラスまたはサブクラスのネットワークメタデータに応答して、特化されたワーキングスレッドおよび／またはポリシモジュールの複数のインスタンス（オブジェクト）を、並行動作するようにインスタンス化（オブジェクト化）することもできる。

例えば、本発明の一実施形態は、内部ネットワーク上に存在する外部制御のネットワークホスト（「ボットネットメンバ」）を検出する固有のケイパビリティを提供する。セントラルコントローラ（「ボットネットマスタ」）によって操作される感染したネットワークホストについて考察されたい。典型的には、ネットワークホスト上の悪意のあるコンテンツを検出するには、そのホスト上に専用のプラグインモジュールをインストールする必要がある。この方法は、ホストベースの手段では検出できない悪意のある高度なエージェント（「ルートキット」）に対して機能しない。本発明の一実施形態は、内部ネットワーク上でのボットネットマスタとボットネットメンバとの間の通信行動を識別してセキュリティシステムに通知することができるポリシを導入する。

ネットワークメタデータ情報の使用に起因して、本発明により提供される知能は、ネットワークトラフィックに曝される類似目的のデバイスにより提供される知能より高度な信頼性を達成する。例えば、悪意のあるトラフィックに曝されるインライン侵入検知システム（ＩＤＳ）または侵入防止システム（ＩＰＳ）は、サービス拒絶（「ＤｏＳ」）攻撃を受ける、またはこれにより損なわれる可能性があるが、本発明は、このような攻撃者がアクセスできない内部ネットワーク上に配備されることが可能である。

さらに、本発明は、ネットワークメタデータの難読化を必要とする配備に適するものにする、ネットワークメタデータの変換を有効化する。

本発明の別の実施形態によれば、本方法およびシステムは、ストリーミング式に実装されてもよく、即ち、入力されるネットワークメタデータを着信されるままに（「リアルタイムで、またはほぼリアルタイムで」）、ネットワークメタデータを持続的に記憶する必要なしに処理するように実装されてもよい。本発明のこの実施形態は、本システムおよび方法を限定されたメモリおよび記憶容量のコンピュータ上へ配備できるようにし、これにより、本実施形態は、クラウドコンピューティングにおける配備に特に適するものとなる。

１つまたは複数のポリシに従ったクラス・メンバ・インスタンスの処理の後、本発明の一実施形態は、ポリシのアプリケーション結果を、変換されたネットワークメタデータまたはオリジナルのネットワークメタデータの受信者によるさらなる処理に適するゼロ、１つまたは複数の表現に変換するための効率的な方法（「コンバータ」）を提供してもよい。その結果、本明細書に開示するシステムおよび方法は、その出力がｓｙｓｌｏｇメタデータと共に用いるべく適応されたＳＩＥＭシステム等の既存の多様なコンポーネントへと方向づけられ得る既存環境における配備に極めてよく適する。

本発明の一実施形態は、１つまたは複数の特定クラスのネットワークメタデータおよび／または出力フォーマット用にカスタマイズされ得る、よって、ネットワーク上でのリアルタイムまたはほぼリアルタイムのサービスをよりよく有効化すべくシステムのスループットを上げる複数のコンバータを提供する。また、システムのパフォーマンスおよびスループットをさらに拡大するために、かなりの量の特定のクラスまたはサブクラスのネットワークメタデータに応答して、カスタム化されたワーキングスレッドおよび／または変換モジュールの複数のインスタンスを、並行動作するようにインスタンス化することもできる。

さらに、本発明の一実施形態は、メッセージ認証コードを添付することによって、変換されたネットワークメタデータの完全性を保証することができる。本発明のこの実施形態は、洗練されたネットワークメタデータ受信者による、受信した情報の信憑性の検証を有効化する。

本発明のさらに別の実施形態は、本システムおよび方法を既存のネットワークエコシステムが透けて見えるように配備する能力である。この実施形態では、既存のネットワークコンポーネントの構成を変更する必要がない。

本発明の別の実施形態は、ネットワークメタデータの処理および変換規則を視覚的に、またはテキスト用語で、もしくはこれらの組み合わせの何れかで記述するための方法および装置を提供する。ポリシの記述が完了しかつ矛盾のないことが検証されれば、規則を遵守するクラスメンバに適用可能なポリシおよびコンバータは、１つまたは複数のネットワークメタデータ処理および変換規則の定義から同時に導出される１つまたは複数の実行可能モジュールとしてインスタンス化されてもよい。その結果、複数のモジュールに渡る体系的なポリシ一貫性が達成される。さらに、このポリシおよび変換規則を実装するモジュールのバイナリ性は、システムが入力されるネットワークメタデータを、同等の処理規則を解釈する環境における処理速度を遙かに超える速度で処理することを可能にする。

本発明をより明白に確認できるように、以下、添付の図面を参照して、幾つかの実施形態を例示として説明する。
図１は、本発明の一実施形態による、分析されることが可能なメタデータを生成する様々なネットワークデバイスを含むネットワークシステムを示す簡略図である。 図２は、メタデータを生成する様々なネットワークデバイスと、このようなメタデータを分析するための本発明の一実施形態によるシステムとを含むネットワークシステムを示す簡略図である。 図３は、本発明の一実施形態による、分析されることが可能なメタデータを生成する様々なネットワークデバイスと、本発明の一実施形態による、分析されたメタデータの提供先であるネットワークデバイスとを含むネットワークシステムを示す簡略図である。 図４は、本発明の一実施形態による、共働してメタデータを分析する様々な処理モジュールを含むネットワークシステムを示す簡略図である。 図５は、本発明の一実施形態による、共働してメタデータを分析する処理モジュールの部分を示すより詳細な略図である。 図６は、本発明の一実施形態による、メタデータの分析に使用され得る１つの論理の流れを示す表である。 図７は、本発明の一実施形態による、メタデータのデータ構造および共働してメタデータを分析する様々な処理モジュールを示す簡略図である。 図８は、本発明の一実施形態による、共働してメタデータを分析する様々な処理モジュールを示す簡略図である。 図９は、本発明の一実施形態による、共働してメタデータを分析する様々な処理モジュールを示す簡易ブロック図およびフローチャートである。 図９ａは、本発明の一実施形態による、実装されることが可能なポリシを示す簡易ブロック図およびフローチャートである。 図９ｂは、本発明の一実施形態による、実装されることが可能な別のポリシを示す簡易ブロック図およびフローチャートである。 図９ｃは、本発明の一実施形態による、実装されることが可能な別のポリシを示す簡易ブロック図およびフローチャートである。 図９ｄは、本発明の一実施形態による、実装されることが可能な別のポリシを示す簡易ブロック図およびフローチャートである。 図９ｅは、本発明の一実施形態による、実装されることが可能な別のポリシを示す簡易ブロック図およびフローチャートである。 図９ｆは、本発明の一実施形態による、実装されることが可能な別のポリシを示す簡易ブロック図およびフローチャートである。 図９ｘは、本発明の一実施形態による、実装されることが可能な別のポリシを示す簡易ブロック図およびフローチャートである。 図１０は、本発明の一実施形態による、ＮｅｔＦｌｏｗメタデータの分析およびＯｐｅｎＦｌｏｗへの変換を示す簡易ブロック図およびフローチャートである。 図１１は、本発明の一実施形態による、Ｓｙｓｌｏｇメタデータの処理を示す簡易ブロック図およびフローチャートである。 図１１ａは、本発明の一実施形態による、大規模ネットワークのブランチサブネットにおけるメタデータの処理を示す簡易ブロック図である。 図１１ｂは、本発明の一実施形態による、大規模ネットワークのブランチサブネットにおけるメタデータの処理を示す簡易ブロック図である。 図１１ｃは、本発明の一実施形態による、クラウドベースの実装におけるネットワーク内でのメタデータの処理を示す簡易ブロック図である。 図１２は、本発明の一実施形態による、ネットワークにおけるメタデータのルーティングを示す簡易ブロック図である。 図１３は、本発明の一実施形態による、ネットワークにおける一般化されたフォーマットのメタデータの分析およびルーティングを示す簡易ブロック図である。

概して、本発明は、ネットワークの監視およびイベント管理に関する。より具体的には、本発明は、ネットワークの監視アクティビティの結果として入手されるネットワークメタデータの処理、およびこれに続くメタデータの処理に関し、これにより、イベント管理エンティティには有益な情報がタイムリーに伝わることになる。

以下の説明では、単に例示を目的として、本発明を、ネットワークメタデータ処理のコンテキストにおいて開示する。しかしながら、本発明が広範なアプリケーションおよび用途に適し、かつ本発明の所定の実施形態がネットワークメタデータ処理以外のコンテキストでも適用可能であることは認識されるであろう。例えば、ＯｐｅｎＦｌｏｗ対応環境において、本システムは、ネットワークからＮｅｔＦｌｏｗ情報を受信し、かつＯｐｅｎＦｌｏｗコントローラへ命令を出力してもよい。

本発明の一実施形態において、本方法およびシステムは、ＮｅｔＦｌｏｗ−ｓｙｓｌｏｇコンバータ（「ＮＦ２ＳＬ」）を用いて実装されてもよい。このコンバータは、ＮｅｔＦｌｏｗバージョン１からバージョン８、ＮｅｔＦｌｏｗ ｖ９、ｊＦｌｏｗ、ｓｆｌｏｗｄ、ｓＦｌｏｗ、ＮｅｔＳｔｒｅａｍ、ＩＰＦＩＸおよびこれらに類似する（「ＮｅｔＦｌｏｗ」）生成者を、ｓｙｓｌｏｇを処理することができるＳＩＥＭシステムと統合できるようにするソフトウェアプログラムである。統合は、ネットワーク上でＮｅｔＦｌｏｗ生成者により生成されるネットワークメタデータをネットワーク監視システムの共通語−ｓｙｓｌｏｇに変換することによって達成される。ＮｅｔＦｌｏｗ情報の対応するｓｙｓｌｏｇ情報へのマッピングは、ＮＦ２ＳＬ管理者により確立されるポリシ、規則および優先順位に従って実行されてもよい。

今日のｓｙｓｌｏｇコレクタ（システムログ収集器）、ｓｙｓｌｏｇアナライザ、ＳＩＭ、ＳＥＭおよびＳＩＥＭシステム、他（以後、纏めて「ＳＩＥＭシステム」と称する）は、ＮｅｔＦｌｏｗの受信および分析ができないか、ＮｅｔＦｌｏｗパケットに含まれる初歩的な情報の処理に限定されているか、処理はできても低速であって結果のタイムリーさおよび有用性が制限される。ＮＦ２ＳＬシステムを介して実装される本発明の実施形態は、ネットワーク上のＮｅｔＦｌｏｗ生成者とＳＩＥＭシステムとの間のインテリジェントな媒介として機能することができ、ＳＩＥＭシステムが他の方法では不可能な細分性、深度および速度で情報にアクセスできるようにする。

ネットワーク上に配備されると、ＮＦ２ＳＬシステムの一実施形態は、概して、ＮｅｔＦｌｏｗパケットを受信し、パケット内のＮｅｔＦｌｏｗレコードを識別しかつ分類し、受信されたパケット内に発見されるＮｅｔＦｌｏｗレコードをＮＦ２ＳＬ管理者により提供されるポリシに照らしてマッチングし、ＮｅｔＦｌｏｗレコードを適用可能なポリシに従って処理し、ＮｅｔＦｌｏｗレコード内の情報をＮＦ２ＳＬ管理者の決定通りにｓｙｓｌｏｇパケットへマッピングし、受信され、統合されかつ／または新たに生成されたＮｅｔＦｌｏｗレコードをＮｅｔＦｌｏｗフォーマット（ネットフローフォーマット）からｓｙｓｌｏｇフォーマット（システムログフォーマット）へ変換し、かつ結果的に生じるｓｙｓｌｏｇパケットを１つまたは複数の指定されたＳＩＥＭシステムへ転送する各機能を包含することができる。このようなＮＦ２ＳＬシステムは、ＳＩＥＭシステムがデータを分析しかつ相関させるために利用可能となる情報ソースの数および有益な情報の量およびタイムリーさを大幅に増大させることができる。

図１は、ヘッドエンドルータ１００と、外部ファイアウォール１０１と、内部ファイアウォール１０２と、「ＤＭＺ」ネットワークにおいてファイアウォール１０１、１０２間に配備される利用可能な公開ウェブサーバ１０３と、データセンタスイッチ１０４と、アプリケーションサーバ１０５とから成る、ある例示的なネットワークを描いている。ある典型的な配備では、上述のエンティティは、生成されるｓｙｓｌｏｇメッセージをＳＩＥＭシステム１０６へ転送するように構成される。ｓｙｓｌｏｇメッセージをＳＩＥＭシステム１０６へ伝達する例示的なエンティティコレクションは、「グループＡ」として識別されている。

図２を参照すると、ＮＦ２ＳＬシステム１０７を用いて実装される本発明の一実施形態がネットワークへ導入される場合、ヘッドエンドルータ１００、外部ファイアウォール１０１、内部ファイアウォール１０２およびデータセンタスイッチ１０４のうちの１つまたはそれ以上は、ＮｅｔＦｌｏｗメッセージをＮＦ２ＳＬシステム１０７へエクスポートするように構成されてもよい。この例示的なネットワークトポロジーにおいて、ＮＦ２ＳＬシステム１０７は、ＮｅｔＦｌｏｗパケットにおいてネットワークメタデータを受信し、ＮｅｔＦｌｏｗレコード（ネットフロー記録、通信記録）を識別しかつ／または分類し、これらのパケット内に発見されるネットワークメタデータをＮＦ２ＳＬ管理者により構成されるポリシに従って処理し（特に関心のあるＮｅｔＦｌｏｗメッセージのフィルタリングおよび統合を含む）、場合により、このような処理の結果として追加的なＮｅｔＦｌｏｗメッセージを生成し、ＮｅｔＦｌｏｗメッセージのうちの選択されたものをｓｙｓｌｏｇメッセージへ効率的に変換し、かつ結果的に生じるｓｙｓｌｏｇメッセージをＳＩＥＭシステム１０６へ転送する。したがって、ＮｅｔＦｌｏｗ生成者からＮＦ２ＳＬシステム１０７に至るまでが構成される、ネットワークのヘッドエンドルータ１００、外部ファイアウォール１０１、内部ファイアウォール１０２、ウェブサーバ１０３、アプリケーションサーバ１０５およびデータセンタスイッチ１０４のネットワークインタフェースは、潜在的な有益情報をＮＦ２ＳＬシステム１０７の仲介によりＳＩＥＭシステム１０６へリアルタイムで、またはほぼリアルタイムで伝達する追加的なエンティティグループを備える。ＮＦ２ＳＬシステムを介してＳＩＥＭシステム１０６へ伝達するエンティティコレクションは、「グループＢ」として識別されている。

情報ソースの数を図１と図２で比較すると、図２におけるＮＦ２ＳＬシステム１０７の導入によって、ＳＩＥＭシステム１０６に対する相関および分析に適するデータを生成する潜在的な情報ソースの数が効果的にはほぼ倍増することを容易に認識できると思われる。本発明のこの態様は、ネットワーク上の状態およびアクティビティに対する可視性を大幅に増大させる。

本発明によるこの実施形態のさらに別の態様は、ＮＦ２ＳＬシステムの実装の多用性である。そのプラットフォーム独立性に起因して、ＮＦ２ＳＬシステムは、無制限に、専用のネットワークアプライアンス上、スタンドアロンサーバ上、クラウドベースのバーチャルマシン上、またはネットワークで結ばれた他の任意のコンピューティングデバイス上に実装されてもよい。その結果、ユーザは、そのニーズおよび予算を最もよく満たすＮＦ２ＳＬ実装を選んでもよい。また、これは、ＮｅｔＦｌｏｗ情報を、ネットワーク上の全てのＮｅｔＦｌｏｗ生成デバイスからではなく、選択されたネットワークデバイスから受信するように実装されてもよい。

図３は、ＮｅｔＦｌｏｗ生成者およびｓｙｓｌｏｇおよびＮｅｔＦｌｏｗコンシューマを伴うＮＦ２ＳＬシステムの例示的な配備を示している。この実施形態では、ＮＦ２ＳＬシステム１０７は、ルータ１２０およびスイッチ１２１によって表されるＮｅｔＦｌｏｗ生成者の例示的なコレクションからＮｅｔＦｌｏｗメッセージ１２２を受信する。受信されたＮｅｔＦｌｏｗメッセージがＮＦ２ＳＬ管理者により供給されるポリシに従って処理されると、ＮＦ２ＳＬシステム１０７は、結果的に生じるｓｙｓｌｏｇメッセージ１２４を、図３上ではＳＩＥＭシステム／ｓｙｓｌｏｇアナライザ１２５およびｓｙｓｌｏｇコレクタ（システムログ収集器）１２６により例示されているｓｙｓｌｏｇ情報コンシューマのコレクションへ転送する。また、所望されれば、ＮＦ２ＳＬシステム１０７は、オリジナルのＮｅｔＦｌｏｗメッセージ、オリジナルＮｅｔＦｌｏｗメッセージのサブセットまたはオリジナルＮｅｔＦｌｏｗメッセージ１２３のスーパーセットをＮｅｔＦｌｏｗコレクタデバイス（ネットフロー収集装置）１２７へ転送するように構成される場合もある。規制上は、ｓｙｓｌｏｇおよびＮｅｔＦｌｏｗメッセージの全てのトラフィックがネットワーク管理者により各々ｓｙｓｌｏｇコレクタ１２６およびＮｅｔＦｌｏｗコレクタ１２７において保持されることの遵守を求める場合が多い。

図３を参照すると、ＮｅｔＦｌｏｗコレクタデバイス１２７が既にネットワーク上に配備され、かつルータ１２０およびスイッチ１２１がＮｅｔＦｌｏｗコレクタデバイス１２７へＮｅｔＦｌｏｗ情報をエクスポートしていた状況において、ＮＦ２ＳＬシステム１０７は、例示として、ＮｅｔＦｌｏｗ生成者のルータ１２０およびスイッチ１２１ならびにＮｅｔＦｌｏｗコレクタデバイス１２７に関し、下記のような異なる幾つかの例示的方法で構成されてもよい。

− ルータ１２０およびスイッチ１２１の構成は、ＮｅｔＦｌｏｗメッセージ１２２をＮＦ２ＳＬシステム１０７へ転送するように修正されてもよく、かつＮＦ２ＳＬシステム１０７は、結果的に生じるＮｅｔＦｌｏｗメッセージ１２３をＮｅｔＦｌｏｗコレクタデバイス１２７へ転送するように構成されてもよい。

− ＮｅｔＦｌｏｗコレクタデバイス１２７のＩＰアドレスは、修正されてＮＦ２ＳＬシステム１０７へ指定されてもよい。よって、ＮＦ２ＳＬシステム１０７は、ＮｅｔＦｌｏｗメッセージ１２２を受信し、かつこれをＮｅｔＦｌｏｗコレクタデバイス１２７の新たに割り当てられたＩＰアドレスへ転送してもよい。

− ＮＦ２ＳＬシステム１０７は、ローカルネットワーク上に流れる全てのトラフィックがＮＦ２ＳＬシステム１０７に明らかであり、よってＮＦ２ＳＬシステムがＮｅｔＦｌｏｗコレクタデバイス１２７に対して完全にトランスペアレントとなる「プロミスキャス」モードで配備されてもよい。ＮＦ２ＳＬシステム１０７のこの配備モードに要する労力は、ＮｅｔＦｌｏｗコレクタデバイス１２７およびルータ１２０およびスイッチ１２１の構成が変わらないことから最小である。ＮＦ２ＳＬシステム１０７のこの配備モードを用いる不利な点は、ＮｅｔＦｌｏｗメッセージ１２２のストリームに影響を与えるポリシの規定がより困難になることにある。この配備モードにおいて、ＮＦ２ＳＬシステム１０７は、依然として追加的なメッセージを生成しかつこれをＮｅｔＦｌｏｗメッセージストリーム１２３へ注入できることは認識されるであろう。

ＮＦ２ＳＬシステムは、好ましくは、最新のマルチコアプロセッサを利用するように設計され、かつマルチスレッド式ソフトウェアまたはファームウェアアプリケーションとして構築されてもよい。

図４は、ＮＦ２ＳＬシステムの機能コンポーネントの例示的なコレクションを反映した一実施形態を描いている。図４を参照すると、ＮＦ２ＳＬの入力スレッド（Ｉ）１４１は、好ましくは、ＮｅｔＦｌｏｗ生成者（例えば、ルータ、スイッチ、他）により発せられるＮｅｔＦｌｏｗメッセージ１４０の受信者として機能する、コンピュータ・プログラミング・コードを介して実装される論理ブロックである。入力スレッド１４１は、複数のＮｅｔＦｌｏｗ生成者から着信するＮｅｔＦｌｏｗメッセージ１４０を「聴く」１つまたは複数が存在してもよい。ある実施形態では、全ての入力スレッド１４１が、構成ポート上で聴く単一のＵＤＰソケットへ結びつけられてもよい。

ＮｅｔＦｌｏｗメッセージ１４０を受信すると、ある入力スレッド１４１は、ＮｅｔＦｌｏｗメッセージ１４０に対して（例えば、そのＮｅｔＦｌｏｗのプロトコルバージョン、ＮｅｔＦｌｏｗメッセージの最小サイズ、他を検証することにより）初期チェックを実行してもよい。受信されたパケットが初期チェックに合格しなければ、入力スレッド１４１は、そのメッセージを廃棄してもよく、またはこれを他の何らかの適切な方法で処理してもよい。パケットが初期チェックに合格すれば、入力スレッド１４１は、これを、同様に好ましくはコンピュータ・プログラミング・コードを介して実装される論理ブロックであるＮＦ２ＳＬワーカ（Ｗ）スレッド１４３のうちの１つへ送ってもよい。ＮＦ２ＳＬシステムのスレッド間通信は、軽量キューメカニズム１４２を介して、または技術上知られる他の任意のメカニズムを介して実装されてもよい。概して、あるＮＦ２ＳＬスレッドは、あるパケットを別のスレッドへ送りたい場合、そのパケットを受信者のスレッドキューに入れてもよい。例えば、キューメカニズム１４２は、ワーカスレッド１４３への供給を行い、かつキューメカニズム１４８は、出力スレッド１４９への供給を行う。パケットをキューに入れると、スレッドは、受信者スレッドへ受信者スレッドが保留中のジョブを有するという信号を送る。

ＮＦ２ＳＬシステムは、受信者スレッドを選ぶ場合、ラウンドロビン方式または技術上知られる他の任意のメカニズムを用いてもよい。他に、無作為の選択、または定義された優先性ステータスに従った選択等の他の選択方法が利用される可能性もあることは認識されるであろう。

ＮＦ２ＳＬワーカスレッド１４３は、ＮＦ２ＳＬ管理者が示すポリシおよびフォーマット変換変形の実行を担当している。ＮＦ２ＳＬポリシは、ＮｅｔＦｌｏｗレコードの処理規則コレクションである。ポリシは、ある特定のＮｅｔＦｌｏｗレコードタイプに適用されても、ＮｅｔＦｌｏｗレコードタイプのグループに適用されても、ＮＦ２ＳＬシステムを流れる全てのＮｅｔＦｌｏｗメッセージに適用されてもよい。好ましくは、ポリシは、ネットワーク内で動作可能な任意のＳＩＥＭシステム１２５において動作可能なポリシ、ならびに配備される任意のｓｙｓｌｏｇおよび／またはＮｅｔＦｌｏｗコレクタの動作を定義するポリシをサポートしかつ／または補足するように定義される。

ポリシを生成する、または定義する場合、ＮＦ２ＳＬ管理者は、１つまたは複数の時間ベースの（「ｋｒｏｎ」）ポリシを指定することもある。ＮＦ２ＳＬ時間ベースポリシは、Ｋｒｏｎ（Ｋ）スレッド１４４によって実行されてもよい。ここに記述したもの以外にも、他のタイプのポリシ、例えば所定のイベント計数、時刻、他によってトリガされるポリシも可能であることが予想される。

ＮＦ２ＳＬ管理者は、ポリシのオーサリングを、内蔵ＧＵＩを介して、ＮＦ２ＳＬソフトウェア開発キット（「ＳＤＫ」）を介して、または技術上知られる他の任意のメカニズムを介して行ってもよい。ＧＵＩ方式を用いる場合、ポリシの定義が完了すると、ＮＦ２ＳＬシステムは、これらのポリシ（ポリシモジュール１４６）、対応する変換変形（変換モジュール１４７）、およびもし定義されていれば、時間ベースのポリシ（時間ベースのポリシモジュール１４５）を実装することができる実行可能なソフトウェアプログラムを生成するように構成される。ある例示的な実施形態では、生成されるソフトウェアプログラムは、動的リンクライブラリ（ＤＬＬまたは「共有オブジェクト」）としてコンパイルされてもよい。これらの共有オブジェクトは、ランタイムにおいてＮＦ２ＳＬシステムにロードされてもよい。あるいは、ポリシ、変換変形および時間ベースポリシは、密接な複数の実行可能モジュールではなく、単一の実行可能モジュールとしてインスタンス化され得ることも予想される。

可能なＮＦ２ＳＬポリシおよび時間ベースポリシの範囲は、ＮｅｔＦｌｏｗ生成者が発する情報の範囲によってのみ限定される。例えば、着信するトラフィックフローに関する情報を含むＮｅｔＦｌｏｗメッセージを伝えるＮｅｔＦｌｏｗ生成者（例えば、ヘッドエンドルータ）について考察されたい。対応するポリシは、ＮＦ２ＳＬシステムに指令して、内部ネットワーク上の特定のｈｔｔｐサーバを宛先とするＩＰパケットの計数を保持し、かつＩＰパケットの累積計数を６０秒毎にＳＩＥＭシステム１２５へ報告させるように定義されてもよい。ＳＩＥＭシステム１２５は、このような情報を効果的に利用して、オペレータに異常なネットワーク状態を知らせることができる。先行技術の実装においてＳＩＥＭシステム１２５へ典型的に配信されるｓｙｓｌｏｇメッセージは、概して、ＳＩＥＭシステム１２５がネットワーク上のこのような状態を認識できるほど十分な情報を包含しない。

ポリシのアレイは、ある特定のレコードタイプに適用可能であるように定義されてもよく、好ましくは、ＮｅｔＦｌｏｗメッセージ１４０において見出される各レコードは、このレコードタイプに適用可能な全てのポリシに照らして評価される。ネットワーク管理者は、あるレコードタイプに関連するポリシアレイの適用順序を定義してもよく、または、他の優先順位論理および／または他の論理を用いてこのような順序が定義されてもよい。ポリシの評価が完了すると、処理モジュール１４６は、ＮｅｔＦｌｏｗレコード処理を続けるべきか、問題のレコードを廃棄すべきかを示す。また、ポリシモジュールは、ＮｅｔＦｌｏｗ生成者から受信される１つまたは複数のオリジナルＮｅｔＦｌｏｗメッセージ１４０と共に、またはその代わりにＮＦ２ＳＬシステムが処理する新しい（派生的な）ＮｅｔＦｌｏｗメッセージを生成することを選んでもよい。ある例示的な実施形態において、時間ベースのポリシにより生成されるＮｅｔＦｌｏｗメッセージは、ポリシによる評価を受けない。本発明の他の実施形態では、時間ベースのポリシにより生成されるＮｅｔＦｌｏｗメッセージが１つまたは複数のポリシによって評価されてもよいことは予想される。

ＮｅｔＦｌｏｗメッセージ１４０の処理の次のステップでは、ワーカスレッド１４３は、ＮｅｔＦｌｏｗレコードを、このＮｅｔＦｌｏｗレコードタイプに適用可能なｓｙｓｌｏｇパケット変換規則（「変換規則」）へ位置づけ、変換モジュール１４７を呼び出して変換手順を実行させる。

ＮＦ２ＳＬ変換規則は、オリジナルのＮｅｔＦｌｏｗメッセージ１４０または派生的なＮｅｔＦｌｏｗレコード１５２を１つまたは複数のｓｙｓｌｏｇまたはＮｅｔＦｌｏｗメッセージ１５０へマップする命令コレクションである。ＮｅｔＦｌｏｗレコード内に見出される情報のｓｙｓｌｏｇを介して伝えられる情報へのマッピングは、ＮＦ２ＳＬ管理者によりＮＦ２ＳＬ ＧＵＩを介して指定される。変換規則の単純な一例は、ＮｅｔＦｌｏｗレコード内の全フィールドのコンテンツをｓｙｓｌｏｇパケット１５０において伝えていく。

ワーカスレッド１４３は、関連する全ての変換規則をＮｅｔＦｌｏｗメッセージ１４０内のレコードに適用すると、結果的に生じるｓｙｓｌｏｇパケットを出力（Ｏ）スレッド１４９のうちの１つへ送り、これが、構成されたｓｙｓｌｏｇおよび／またはＮｅｔＦｌｏｗメッセージのコンシューマへと配信される。

ＮＦ２ＳＬシステムにおける入力スレッド１４１、ワーカスレッド１４３および出力スレッド１４９の数が設定可能であること、およびＮＦ２ＳＬシステムが、入力スレッド１４１、ワーカスレッド１４３および出力スレッド１４９の複数のインスタンスが並列で動作し得ることに起因して遙かに大量のメッセージトラフィックを処理できることは認識されるべきである。

ＮＦ２ＳＬシステムの輻輳制御メカニズム

ある例示的な実施形態では、ＮｅｔＦｌｏｗのトラフィックバーストに対処するために、ＮＦ２ＳＬシステムは輻輳制御メカニズムを含んでもよい。図５を参照すると、ＮＦ２ＳＬシステムは、ＷＲＥＤ（「重み付けランダム早期検出」）方式を用いてワーク・スレッド・キュー１６３の輻輳レベルを決定してもよい。

各ワークスレッド１６５は、限定サイズの即時ワーク・スレッド・キュー１６３と、制限のないワークスレッドＷＲＥＤキュー１６４とを有してもよい。入力スレッド１６１は、ＮｅｔＦｌｏｗメッセージＭＳＧ１６０を受信すると、このＮｅｔＦｌｏｗメッセージＭＳＧ１６０を処理すべきワークスレッド１６５を選択する。ワークスレッド１６５の選択は、ラウンドロビン様式で行われても、効果的であるとされる他の任意の方式で行われてもよい。ワークスレッド１６５が選択されると、入力スレッド１６１は、着信パケットをワークスレッド１６５のどのキューに入れるべきかを決定するＷＲＥＤオラクル１６２を調べる。ＷＲＥＤオラクル１６２は、この決定を、ワーク・スレッド・キュー１６３の現行長さ、およびＷＲＥＤ方式のガイドラインに従って計算されるキューの平均長さを基礎として下してもよい。

通常の負荷状態の下では、ＷＲＥＤオラクル１６２は、入力スレッド１６１にパケットをワーク・スレッド・キュー１６３に入れるように命令してもよい。トラフィック量が多い場合、ＷＲＥＤオラクル１６２は、確率的手法を用いて、ＮｅｔＦｌｏｗメッセージＭＳＧ１６０がワーク・スレッド・キュー１６３に入れられるべきか、ワークスレッドＷＲＥＤキュー１６４に入れられるべきかを決定してもよい。トラフィック量が増すにつれて、ＮｅｔＦｌｏｗメッセージＭＳＧ１６０がワークスレッドＷＲＥＤキュー１６４に入れられる確率は高まり得る。

ＮｅｔＦｌｏｗパケットＭＳＧ１６０がワークスレッドＷＲＥＤキュー１６４へ転送される確率は、ＮｅｔＦｌｏｗメッセージＭＳＧ１６０のある特定のソースに関連づけられる重量にも依存する場合がある。ＮｅｔＦｌｏｗソースの重量は、ＮＦ２ＳＬ管理者によって決定されてもよい。

ＮＦ２ＳＬシステムにおいて、輻輳制御という目的に関しては、ＷＲＥＤ以外のアルゴリズムが使用される可能性もあることは認識されるべきである。例えば、ＮＦ２ＳＬシステムにおける輻輳を軽減するために、オリジナルのＲＥＤ（「ランダム早期検出」）アルゴリズム、ＡＲＥＤ（「適応ランダム早期検出」）、シスコシステムズ社のＤＢＬ（「動的バッファ制限」）、他が使用される可能性もある。

ＮＦ２ＳＬシステムのＮｅｔＦｌｏｗトラフィック処理規則

再度図４を参照すると、ＮＦ２ＳＬシステムは、専用の変換モジュール１４７を持たないＮｅｔＦｌｏｗレコードを変換するためにＮＦ２ＳＬ管理者が有効化し得るデフォルト（初期設定）の変換モジュール１５１を含んでもよい。デフォルトの変換モジュール１５１は、ＮｅｔＦｌｏｗレコードフィールドを下記のようにフィールドのＮｅｔＦｌｏｗタイプｉｄが先行してコロン（「：」）で分離されるタイプ指定フォーマットのＡＳＣＩＩストリングとしてマップするデフォルトの変換規則を実装してもよい。

＜レコードフィールドｉｄ＞：＜レコードフィールド値＞

図６は、レコード指定のポリシおよび変換規則が設定されている場合と設定されていない場合、および図４上のデフォルトの変換モジュール１５１が有効化される場合と有効化されない場合の、タイプＲのＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコード（「レコードＲ」）の例示的な処理を示す。ＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードの処理に関しては、他に、ポリシも変換規則またはデフォルトの変換規則も設定されていない場合には受信されるＮｅｔＦｌｏｗメッセージをドロップする、他等の選択肢も存在し得ることは予想される。

一般的なイベント報告プロトコルが、配信される情報の完全性を保証するための内蔵メカニズムを準備していないことは認識されるべきである。ＮＦ２ＳＬシステムは、ＮＦ２ＳＬシステムにより生成される出力メッセージへチェックサムまたは他の完全性保証エレメントを添付することができる高度な機能を提供する。チェックサムは、ＣＲＣ−１６等のチェックコード、ｍｄ５、ｓｈａ−１、ＦＮＶまたはその一部等のメッセージハッシュ、またはＨＭＡＣ等のキー式認証コードであってもよい。チェックサムの存在により、情報の受信者は、メッセージの受信時またはその後の何れかでその信憑性を検証することができる。

ＮｅｔＦｌｏｗ ｖ９のデータＦｌｏｗＳｅｔレコードｉｄの識別と追跡

ＮｅｔＦｌｏｗ ｖ９プロトコルは、ＲＦＣ３９５４に記述されているように、ネットワーク管理者に、豊富なネットワークフロー記述を生成するためのメカニズムを提供している。このメカニズムは、テンプレートＦｌｏｗＳｅｔおよびオプションテンプレートＦｌｏｗＳｅｔの概念を基礎とする。テンプレートは、ランタイムにおいてＮｅｔＦｌｏｗ生成者により発せられるＮｅｔＦｌｏｗデータレコードのフィールドタイプおよびフィールドサイズのリストである。例えば、あるテンプレートフィールドは、あるフローにおいて観察されるバイトの数を含んでもよい。あるオプションテンプレートは、ＮｅｔＦｌｏｗ生成者に関する情報を含むＮｅｔＦｌｏｗレコードのフィールドタイプおよびフィールドサイズのリストである。例えば、あるオプション・テンプレート・フィールドは、ＮｅｔＦｌｏｗ情報を発するＮｅｔＦｌｏｗ生成者のインタフェースのフルネームを含んでもよい。

ＮｅｔＦｌｏｗ ｖ５と呼ばれるＮｅｔＦｌｏｗ ｖ９に先行するプロトコルは、単一タイプのデータレコードを定義している。ＮｅｔＦｌｏｗ ｖ５レコードが、ＮｅｔＦｌｏｗ ｖ９プロトコルのテンプレートファシリティ（装置、装備）によって記述され得ることは認識される。この手法は、ＮＦ２ＳＬポリシおよび変換メカニズムの利点をＮｅｔＦｌｏｗ ｖ５生成者へ拡張できるようにする。

ＮｅｔＦｌｏｗバージョン９の導入により、ＮｅｔＦｌｏｗメッセージは、遙かに大量の可変性および対応する情報および意味によって生成される可能性もある。例えば、ＮｅｔＦｌｏｗバージョン９のメッセージは、ＮｅｔＦｌｏｗ ｖ５メッセージのフィールドの全てを包含することができ、かつ場合により、マルチプロトコル・ラベル・スイッチング（ＭＰＬＳ）のラベルおよびＩＰｖ６アドレスおよびポート等の追加情報を含むことができる。しかしながら、有用性は高まるものの、ＮｅｔＦｌｏｗ ｖ９メッセージを解釈しかつ用いるように設計されるシステムは、さらに複雑なものになっている。バージョン９のエクスポートフォーマットは、テンプレートを用いて、ＩＰパケットフローの観察へのアクセスを柔軟かつ拡張可能式に提供する。テンプレートは、フィールドおよびフィールド長さのコレクションを、対応する構造体および意味の記述を添えて定義する。

以下、ＮｅｔＦｌｏｗ ｖ９に関連づけられる有用な用語の幾つかを挙げて論じる。

ＩＰフロー、またはフロー：フローとも呼ばれるＩＰフローは、所定の時間間隔の間にネットワーク内の観察ポイントを通るＩＰパケットセットである。ある特定のフローに属する全てのパケットは、パケットに含まれるデータから、かつ観察ポイントにおけるパケット処理から導出される共通の特性セットを有する。

エクスポータ：エクスポータは、ＮｅｔＦｌｏｗサービスが有効化されているデバイス（例えば、ルータ）である。エクスポータは、観察ポイントに入ってくるパケットを監視して、これらのパケットからフローを生成する。これらのフローからの情報は、フローレコードの形式でエクスポート（流出）される。

エクスポートパケット：エクスポートパケットは、エクスポータを起源（発生源、流出源）として、このエクスポータのフローレコードを伝送するパケットであり、その宛先は、本発明のＮｅｔＦｌｏｗコレクタまたはＮＦ２ＳＬであってもよい。

パケットヘッダ：パケットヘッダは、エクスポートパケットの最初の部分である。パケットヘッダは、ＮｅｔＦｌｏｗバージョン、パケットに包含されるレコード数およびシーケンスの付番等の、パケットに関する基本情報を提供する。

テンプレートレコード：テンプレートレコードは、あるフロー・データ・レコードにおけるフィールドの構成および解釈を定義する。

テンプレートＩＤ：テンプレートＩＤは、あるテンプレートレコードに一時的に関連づけられる数値である。

テンプレート・フロー・セット：テンプレート・フロー・セットは、テンプレートレコードを過渡的なテンプレートＩＤに関連づける構造体である。

フロー・データ・レコード：フローレコードは、観察ポイントで観察されるＩＰフローに関する情報を提供する。フロー・データ・レコードは、テンプレートレコードに対応するフローパラメータの値を含むデータレコードである。

データ・フロー・セット：データ・フロー・セットは、１つまたは複数のフロー・データ・レコードを同じテンプレートＩＤで纏める構造体である。

したがって、かつ図７を参照すると、ＮｅｔＦｌｏｗ ｖ９のフロー・データ・レコード２０４は、ＮｅｔＦｌｏｗ ｖ９のフロー・データ・レコード２０４を周知の定義にバインドする固有の識別子を保有しなくてもよい。代わりに、ＮｅｔＦｌｏｗ ｖ９のエクスポータは、周期的に、テンプレートＩＤ２０２と呼ばれる値によって識別されるＮｅｔＦｌｏｗ ｖ９のレコードテンプレートＦｌｏｗＳｅｔ２００を発する。テンプレートＩＤ２０２のレコードタイプ識別子は、特定のＮｅｔＦｌｏｗ ｖ９フロー・データ・レコードへバインドされず、経時的に、例えばＮｅｔＦｌｏｗエクスポータの構成が変わる場合、またはエクスポータデバイスが再起動する場合に変わってもよい。したがって、フロー・データ・レコード２０４のコンテンツおよび意味の定義は、予測不能に変わる可能性があるテンプレートに依存する。

ＮＦ２ＳＬシステムの例示的な一実施形態は、ＮｅｔＦｌｏｗ ｖ９フロー・データ・レコード２０４の定義および同一性を決定しかつ追跡する新規手法を提供する。この同じ方法または類似方法が、ＮｅｔＦｌｏｗ ｖ９から導出される、またはその意味でＮｅｔＦｌｏｗ ｖ９に類似するＩＰＦＩＸ、ＮｅｔＳｔｒｅａｍ、ｓｆｌｏｗｄ、他等のプロトコルのネットワーク・メタデータ・レコードの同一性の決定および追跡についても適用可能であることは認識されるべきである。

テンプレートＩＤ２０２の値の変化に対応するために、ＮＦ２ＳＬシステムは、ＮｅｔＦｌｏｗ ｖ９のテンプレートＦｌｏｗＳｅｔセクション２０１のチェックサムを計算する。テンプレートＩＤフィールド２０２およびフィールド計数フィールド２１７が、チェックサムに包含される必要はない。ＮｅｔＦｌｏｗ ｖ９のテンプレートＦｌｏｗＳｅｔセクション２０１上で計算されるチェックサム値は、「レコードフィンガープリント」と呼ばれる場合がある。

所定のＮｅｔＦｌｏｗ ｖ９データタイプは、可変長さを有するものとして定義される（例えば、インタフェースを短縮したネーム、およびフルネームを含むＩＦ＿ＮＡＭＥまたはＩＦ＿ＤＥＳＣ）。１つまたは複数の可変サイズフィールドを含むレコードのレコードフィンガープリントを計算する場合、このようなフィールドの長さは０であるものとされてもよい。

チェックサム値が、ｍｄ５、ｓｈａ−１、ｓｈａ−２５６、ＦＮＶ、他を含む、但しこれらに限定されない幾つかのアルゴリズムを用いて計算され得ることは認識されるべきである。図７の例示的な実施形態では、ＮＦ２ＳＬシステムは、ｍｄ５アルゴリズムを用いてＮｅｔＦｌｏｗ ｖ９データ・フロー・レコード２０４のフィンガープリントを計算している。

ＮＦ２ＳＬシステムに登録する場合、各コンバータおよびポリシモジュールは、このモジュールがポリシまたは変換規則の何れか、または双方を実装するＮｅｔＦｌｏｗ ｖ９のデータ・フロー・セット２０３の関数ベクトルおよびｍｄ５フィンガープリント値を供給してもよい。ＮＦ２ＳＬシステムは、このフィンガープリントおよびモジュールの関数ベクトルをコンテナＦ２０５に保存することができる。

ＮｅｔＦｌｏｗ ｖ９のプロトコルによれば、所定のレコードタイプのＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔメッセージ２０３の放出に先行して、ＮｅｔＦｌｏｗ ｖ９のエクスポータは、後続のＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔメッセージ２０３を所定の過渡的なテンプレートＩＤ値２０２、Ｉｄ０に関連づける個々のテンプレートＦｌｏｗＳｅｔメッセージ２００を発する。ＮＦ２ＳＬシステムは、ＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔ２００のレコードフィンガープリント値、ｆｉを計算することができ、かつこれを、この特定のテンプレートＦｌｏｗＳｅｔ２００に対応するエントリ（記録、登録）をコンテナＦ２０５内に位置決めするためのキーとして用いることができる。コンテナＦ２０５内の対応するエントリが発見されれば、ＮＦ２ＳＬシステムは、コンテナＲ２０６内にオブジェクトｒｍ２０８を生成することができる。

複数のＮｅｔＦｌｏｗ ｖ９エクスポータを識別するために、ＮＦ２ＳＬシステムは、ＮｅｔＦｌｏｗ ｖ９エクスポータのソースＩＤおよびソースＩＰアドレスを過渡的なテンプレートＩＤ２０２、Ｉｄ０と共に用いることができる。この情報は、オブジェクトｒｍ２０８内に{Ｉｄ０，ソースＩＤ，ソースＩＰアドレス}タプル２１１として記憶されてもよい。

{Ｉｄ０，ソースＩＤ，ソースＩＰアドレス}タプル２１１に加えて、オブジェクトｒｍ２０８は、オブジェクトｒｍ２０８が関連づけられるコンテナＦ２０５内のオブジェクトｆｉ２０７に対する参照ｒｅｆ（ｆｉ）２０９も有する場合がある。オブジェクトｆｉ２０７に関連づけられるオブジェクトがコンテナＲ２０６内に２つ以上存在すれば、コンテナＲ２０６内のこれらのオブジェクトに対する参照は、纏めてｆｉへの参照のコンテナ２１０内に入れられる。

ある例示的な実施形態では、コンテナＦ２０５およびコンテナＲ２０６は、ＡＶＬ木として実装される。ｆｉへの参照のコンテナ２１０は、ソートされるリストとして実装される。コンテナＦ２０５、コンテナＲ２０６およびｆｉへの参照のコンテナ２１０が、ハッシュテーブル、リンクリスト、赤黒木、他等の異なる様式で実装される可能性もあることは認識されるであろう。

ある例示的な実施形態において、ＮＦ２ＳＬシステムは、テンプレートＩＤ２０２値がＩｄ０であるＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔ２０３を受信すると、コンテナＲ２０６内の{Ｉｄ０，ソースＩＤ，ソースＩＰアドレス}タプル２１１を検索し、かつ参照ｒｅｆ（ｆｉ）２０９を用いてオブジェクトｆｉ２０７をコンテナＦ２０５内に位置決めする。オブジェクトｆｉ２０７は、ＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔ２０３に適用可能なポリシを実行するポリシモジュールの関数ベクトルを含んでもよい。同じ検索手順を繰り返して、ＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔ２０３に適用可能な変換規則が位置決めされ、かつ実行される。

既知のソースＩＤ、ＳＩＤ、およびソースＩＰアドレス、ＳＲＣに対して、新しいＮｅｔＦｌｏｗ ｖ９テンプレートＦｌｏｗＳｅｔ２０５のテンプレートＩＤ２０２が導入される場合、以下のシナリオが考慮され得ることは認識されるであろう。ＮｅｔＦｌｏｗ ｖ９のテンプレートＦｌｏｗＳｅｔセクション２０１上で計算されるデータ・フロー・レコード２０４のフィンガープリント値は変化せず、よってオブジェクトｆｉ２０７がコンテナＦ２０５内へ容易に位置決めされる可能性もある点に留意することは有益である。

シナリオ１：ＮｅｔＦｌｏｗ ｖ９の生成者は、テンプレートＦｌｏｗＳｅｔ ｆｉのテンプレートＩＤ２０２をＩｄ０からＩｄ１へ変更する。

この場合、コンテナＲ２０６内にタプル｛Ｉｄ１，ＳＩＤ，ＳＲＣ｝２１１は存在しない。ＮＦ２ＳＬシステムは、タプル｛Ｉｄ１，ＳＩＤ，ＳＲＣ｝２１５を保持するオブジェクトｒｋ２１２を生成することができ、かつこれをコンテナＲ２０６へ、およびｆｉへの参照のコンテナ２１０へ挿入することができる。タプル｛Ｉｄ０，ＳＩＤ，ＳＲＣ｝に関連づけられる先に存在するオブジェクトは、ｆｉへの参照のコンテナ２１０およびコンテナＲ２０６から、後のアイドルオブジェクト除去手順の間に、またはタプル｛Ｉｄ１，ＳＩＤ，ＳＲＣ｝２１５がコンテナＲ２０６およびｆｉへの参照のコンテナ２１０へ挿入された直後に除去されてもよい。

シナリオ２：ＮｅｔＦｌｏｗ ｖ９の生成者は、先行して知られるテンプレートＦｌｏｗＳｅｔ ｆｉのテンプレートＩＤ（これは、もはや使用されない）のそれと同じであるテンプレートＩＤ、Ｉｄ１を有するテンプレートＦｌｏｗＳｅｔｆｊを導入する。

この場合、コンテナＲ２０６には、オブジェクトｒｋ２１２タプル｛Ｉｄ０，ＳＩＤ，ＳＲＣ｝２１１がオブジェクトｒｋ２１２内に既に存在する。ＮＦ２ＳＬシステムは、オブジェクトｒｋ２１２をコンテナＲ２０６内に位置決めし、かつオブジェクトｒｋ２１２が、先に参照されたテンプレートＦｌｏｗＳｅｔ ｆｉ２０７ではなく、異なるテンプレートＦｌｏｗＳｅｔ ｆｊ２１３を参照しているものと推測する。ＮＦ２ＳＬシステムは、テンプレートＦｌｏｗＳｅｔ ｆｉ２０７およびテンプレートＦｌｏｗＳｅｔ ｆｊ２１３のフィンガープリント値を比較して不一致を検出してもよい。すると、ＮＦ２ＳＬシステムは、オブジェクトｒｋ２１２をｆｉへの参照のコンテナ２１１から除去し、参照ｒｅｆ（ｆｉ）２０９を除去し、かつこれを、オブジェクトｆｊ２１３をポイントする参照ｒｅｆ（ｆｊ）２１４で置換する。また、これは、オブジェクトｒｋ２１２をｆｊへの参照のコンテナ２１６へも挿入する場合がある。

シナリオ３：ＮｅｔＦｌｏｗ ｖ９の生成者は、値Ｉｄ０を変えることなくテンプレートＦｌｏｗＳｅｔ ｆｉのテンプレートＩＤ２０２をリフレッシュする。

この場合、コンテナＲ２０６には、タプル｛Ｉｄ０，ＳＩＤ，ＳＲＣ｝２１１がオブジェクトｒｍ２１２内に既に存在する。ＮＦ２ＳＬシステムは、オブジェクトｒｍ２１２をコンテナＲ２０６内に位置決めし、かつこれが、先と同じテンプレートＦｌｏｗＳｅｔ ｆｉを参照しているものと推測する。ＮＦ２ＳＬシステムは、それ以上の行動は起こさない。

ＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔオブジェクトのＮＦ２ＳＬシステムへの登録

ｖ９に先行するＮｅｔＦｌｏｗプロトコルバージョンは、バージョン毎に１つのデータタイプのみをサポートしている。これらのデータタイプは、ＮＦ２ＳＬシステムにおいて、その個々の文書記述を基礎として登録されてもよい。

先に論じたように、ＮｅｔＦｌｏｗ ｖ９のプロトコル、その派生物およびこれに取って代わるものは、任意のデータタイプをサポートする。これらのデータタイプは、ＮｅｔＦｌｏｗ ｖ９テンプレートＦｌｏｗＳｅｔの構成概念によって記述される。

ＮｅｔＦｌｏｗ ｖ９のデータＦｌｏｗＳｅｔが１つまたは複数のｓｙｓｌｏｇメッセージに変換されるためには、データＦｌｏｗＳｅｔの定義がＮＦ２ＳＬシステムに知らされなければならない。ある例示的な実施形態では、ＮＦ２ＳＬシステムは、ＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔの定義を捕捉するために、以下の方法を用いる。

１．ＮｅｔＦｌｏｗ ｖ９のプロトコルによれば、ＮｅｔＦｌｏｗ ｖ９のプロトコルは、データＦｌｏｗＳｅｔのエクスポートに先行して、エクスポートされるべきＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔオブジェクトについて記述するテンプレートＦｌｏｗＳｅｔおよびオプションテンプレートＦｌｏｗＳｅｔメッセージを発しなければならない。ＮＦ２ＳＬシステムは、ＮｅｔＦｌｏｗ生成者によりエクスポートされるＮｅｔＦｌｏｗ ｖ９テンプレートＦｌｏｗＳｅｔメッセージを捕捉し、かつこれらを内部ＸＭＬ表現で保存してもよい。

２．ＮｅｔＦｌｏｗ ｖ９の生成者（例えば、シスコのＩＯＳ、ジュニパーネットワークスのＪｕｎＯＳ、他）は、ＮｅｔＦｌｏｗ ｖ９情報を構成してエクスポートするための包括的なコマンド・ライン・インタフェースを提供する。ＮＦ２ＳＬシステムは、ＮｅｔＦｌｏｗ生成者からのＮｅｔＦｌｏｗ関連設定の抽出、およびその内部ＸＭＬ表現への変換をサポートする。

３．ＮＦ２ＳＬシステムは、ＮｅｔＦｌｏｗ ｖ９のデータＦｌｏｗＳｅｔ定義を細かく規定するためのＧＵＩツールを提供する。ＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔの定義は、内部ＸＭＬ表現で記憶される。

ＮｅｔＦｌｏｗ ｖ９テンプレートＦｌｏｗＳｅｔレコードの定義が捕捉されると、ＮＦ２ＳＬ管理者は、ＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔ情報のｓｙｓｌｏｇパケットへのマッピングを指定するために、かつ／またはこのＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔ処理のポリシを定義するために、この定義を用いてもよい。

ＮＦ２ＳＬシステムの他の実施形態が、上述の方法以外のＮｅｔＦｌｏｗ ｖ９データＦｌｏｗＳｅｔ定義の捕捉方法を実装し得ることは予想される。

ＮＦ２ＳＬポリシおよび変換メカニズム

図８を参照すると、ある例示的な実施形態において、ＮＦ２ＳＬシステムは、ＮＦ２ＳＬ管理者が、ＮＦ２ＳＬシステムをトラバースするＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔオブジェクトが処理される方法に影響を与えるポリシを生成できるようにする。ＮＦ２ＳＬシステムのポリシは、コンテンツベース（「コンテンツポリシ」）であっても、時間ベース（「ｋｒｏｎポリシ」）であっても、他の要素を基礎とするものであってもよい。このＮＦ２ＳＬシステムにおいて、ポリシは、ＮＦ２ＳＬポリシマネージャ２４１によって管理されてもよく、かつ実行可能なポリシモジュール２４２によって実行されてもよい。

ある例示的な実施形態において、ＮＦ２ＳＬシステムのポリシモジュール２４２は、好ましくは標準化されたインタフェースを提供する動的にロードされる実行可能拡張子（ＤＬＬまたは「共有オブジェクト」）である。ＮＦ２ＳＬポリシマネージャ２４１は、ポリシモジュール２４２を動的にロードし、かつそのインタフェースの関数ベクトルを、周知のエントリポイント関数を呼び出すことによって発見することができる。ポリシモジュール２４２の関数ベクトルは、ロードされるポリシモジュール２４２に含まれるコンテンツベースまたは時間ベースのポリシ関数を実装する関数を指す関数ポインタアレイを含んでもよい。

ＮＦ２ＳＬポリシマネージャ２４１は、そのデータＦｌｏｗＳｅｔレコードフィンガープリントに一致するＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔオブジェクトにポリシを適用する。コンテンツベースのポリシは、データＦｌｏｗＳｅｔ当たりゼロまたはそれ以上の数で存在してもよい。コンテンツベースのポリシは、ＮＦ２ＳＬ管理者によって各コンテンツベースのポリシに割り当てられる優先性の順位でデータＦｌｏｗＳｅｔに適用される。

ＮＦ２ＳＬポリシマネージャ２４１は、入力メッセージ２４０において提出されるデータＦｌｏｗＳｅｔをパースし、かつこのデータＦｌｏｗＳｅｔにおいて見出される各ＮｅｔＦｌｏｗレコードを２５１において関連のポリシモジュール２４２へ送ることができる。ＮｅｔＦｌｏｗレコードの処理に際して、ポリシモジュール２４２は、入力メッセージ２４０における問題のゼロまたはそれ以上のＮｅｔＦｌｏｗレコードが、さらなる処理のために２５２において転送されるべきであると決定してもよく、さらなる検討には値しないものとして２５０においてＮｅｔＦｌｏｗレコードをマーキングしてもよく、機密情報を難読化するためにＮｅｔＦｌｏｗレコードデータを意図的に修正してもよく、または１つまたは複数の派生メッセージ２４３を生成してもよい。循環処理の可能性を回避するために、ＮＦ２ＳＬポリシモジュール２４２により生成される派生メッセージは、ＮＦ２ＳＬコンテンツベースポリシと整合される必要はなく、直にＮＦ２ＳＬ変換マネージャ２４４へ転送されてもよい。

時間ベースの（「ｋｒｏｎ」）ポリシは、ＮＦ２ＳＬ Ｋｒｏｎポリシマネージャ２４６によって周期的に呼び出されてもよい。ｋｒｏｎポリシは、Ｋｒｏｎポリシモジュール２４７によって実行される。ｋｒｏｎポリシを呼び出す頻度は、ｋｒｏｎポリシをＮＦ２ＳＬ Ｋｒｏｎポリシマネージャ２４６に登録する時点で規定されてもよい。ｋｒｏｎポリシは、管理する情報に対して任意のアクションを実行してもよく、さらに、１つまたは複数のＫｒｏｎメッセージ２４８を発してもよい。Ｋｒｏｎメッセージ２４８は、概して、ＮＦ２ＳＬコンテンツベースポリシに整合される必要はなく、直にＮＦ２ＳＬ変換マネージャ２４４へ転送されてもよいが、代替挙動も可能である。

ＮＦ２ＳＬシステムのこの実施形態では、変換規則はＮＦ２ＳＬ変換マネージャ２４４によって管理され、かつ実行可能な変換モジュール２４５によって実装される。

ある例示的な実施形態において、ＮＦ２ＳＬシステムの変換モジュール２４５は、好ましくは標準化されたインタフェースを提供する動的にロードされる実行可能拡張子（ＤＬＬまたは「共有オブジェクト」）である。ＮＦ２ＳＬ変換マネージャ２４４は、変換モジュール２４５を動的にロードし、かつそのインタフェースの関数ベクトルを、周知のエントリポイント関数を呼び出すことによって発見する。変換モジュール２４５の関数ベクトルは、入力メッセージ２４０、派生メッセージ２４３およびＫｒｏｎメッセージ２４８において見出されるＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードを１つまたは複数のｓｙｓｌｏｇ出力メッセージ２４９に変換する関数を指す関数ポインタを含む。

ＮＦ２ＳＬポリシおよび変換規則表現

図９を参照すると、ＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードの定義２６０は、ポリシおよび変換規則の作成手順において利用されてもよい。ＮＦ２ＳＬシステムにおいて、ＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードは、このレコードのＮｅｔＦｌｏｗ ｖ９スタイルテンプレートＦｌｏｗＳｅｔ定義上で計算されるチェックサム値によって一意に識別されてもよい。ＮｅｔＦｌｏｗ ｖ５のレコードも、ＮｅｔＦｌｏｗ ｖ９スタイルのテンプレートＦｌｏｗＳｅｔによってモデリングされてもよい。ある例示的な実施形態において、ＮＦ２ＳＬは、ＸＭＬフォーマットを用いてＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードの定義２６０を表現する。

ＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードの定義２６０を作成した後、ＮＦ２ＳＬ管理者は、ＧＵＩツールまたはＮＦ２ＳＬ ＳＤＫを用いてポリシおよび変換規則を作成してもよい。ＮＦ２ＳＬ管理者は、ポリシおよびｋｒｏｎポリシ２６１および変換規則２６２のグラフィック表現を作成してもよい。ＮＦ２ＳＬシステムは、ＧｒａｐｈＭＬ ＸＭＬ構文を用いてこのグラフィック表現をテキスト表現に変える。

ポリシおよびｋｒｏｎポリシ２６１および変換規則２６２のグラフィック表現が完成すると、ＧｒａｐｈＭＬ表記は、ポリシおよびｋｒｏｎポリシ２６３および変換規則２６４を記述する一連の規則に変えられてもよい。一連の規則は、ＲｕｌｅＭＬ構文を用いて書かれてもよい。

ポリシおよびｋｒｏｎポリシ２６３および変換規則２６４のＲｕｌｅＭＬ表現は、機械プログラミング言語で書かれる等価の規則シーケンスに変えられてもよく、これは、バイナリ表現にコンパイルされて効率的に実行されてもよい。変換の結果として、プログラミング言語の用語でポリシおよびｋｒｏｎポリシ２６５および変換規則２６６を記述する２つのモジュールが生じる。続くコンパイルの結果、ポリシおよびｋｒｏｎポリシ２６７および変換規則２６８を実装する２つの実行可能なバイナリモジュールが生じる。

ある例示的な実施形態では、ポリシおよびｋｒｏｎポリシ２６５および変換規則２６６をプログラミング言語の用語で提示する場合、ＮＦ２ＳＬシステムは、機械プログラミング言語の選択肢として「Ｃ」プログラミング言語を用いる。ポリシおよびｋｒｏｎポリシ２６５および変換規則２６６、およびポリシおよびｋｒｏｎポリシ２６７および変換規則２６８が、複数のオブジェクトであるよりも、１つのオブジェクトに統合され得ることは認識されるであろう。

また、ポリシおよび変換規則を表現するために、ＧｒａｐｈＭＬ、ＲｕｌｅＭＬおよび「Ｃ」プログラミング言語以外の構文が使用され得ることも認識されるであろう。本発明の好適な一実施形態の有益な態様は、ポリシおよび変換規則を実装するための実行可能な専用モジュールの提案である。この実施形態のこの態様は、入力データを解釈する類似目的のシステムより少なくとも１０倍は速いパフォーマンスを保証する。

ＮＦ２ＳＬポリシ

コンテンツベースのＮＦ２ＳＬポリシは、概して、外部のＮｅｔＦｌｏｗ生成者により発せられるＮｅｔＦｌｏｗトラフィックに関連づけられるが、時間ベースのポリシは、典型的には、オリジナルのＮｅｔＦｌｏｗトラフィックの処理によって結果的に生じるデータを処理し、かつ追加のＮｅｔＦｌｏｗ情報を発する。以下のＮＦ２ＳＬポリシ、ポリシパラメータおよびポリシ実装は例示的であり、よって本明細書に明示されるもの以外の方法で実行され得ることは認識されるべきである。

図９ａは、ＮｅｔＦｌｏｗテンプレートＸ４００の例示的なコンテンツベースポリシ、およびＮｅｔＦｌｏｗテンプレートＹ４０１を発する例示的な時間ベースポリシを示す。ＮｅｔＦｌｏｗテンプレートＸ４００は、次の例示的なフィールドを含む。


ｓｒｃ＿ｉｐ＿ａｄｄｒ−フローソースのＩＰアドレス
ｓｒｃ＿ｐｏｒｔ−フローソースのポート
ｄｓｔ＿ｉｐ＿ａｄｄｒ−フロー宛先のＩＰアドレス
ｄｓｔ＿ｐｏｒｔ−フロー宛先のポート
ｉｎ＿ｐｋｔｓ−フロー内のパケット数
ｉｎ＿ｂｙｔｅｓ−フロー内のバイト数
ａｐｐ＿ｔａｇ−フローに関連づけられるアプリケーションのｉｄ

テンプレートＸ４００は、この例に関係しない他のフィールドを有してもよい。

コンテンツベースのフィルタリングポリシは、擬似コード構文を用いて次のように表されてもよい。

for all Data FlowSet records of type X:
if (dst_port == 80 or dst_port == 443) {
accumulatein_pkts counter;
accumulatein_bytes counter;
ignore record;
}
else if (application == directory_service) {
report event;
}
else ignore record;

上述の擬似コードは、人が見て読み取れる次のようなポリシ記述に相当する。

「タイプＸのデータＦｌｏｗＳｅｔレコードを観察する。

レコードが、ウェブサービス（「ｈｔｔｐ：８０」または「ｈｔｔｐｓ：４４３」）宛のフローを記述していれば、フロー内のパケット数およびフロー内に観察されるバイト数をこれらのウェブサービスを宛先とする先に観察されたパケットおよびバイトの数に加算する。レコードは、転送しないこと。

レコードが、ディレクトリサービスへのフローを記述していれば、レコードを転送する。

そうでなければ、レコードを転送しないこと。」

本発明の一実施形態において、ＮＦ２ＳＬ管理者は、上述のポリシの定義を、ＮＦ２ＳＬＧＵＩツールを用いて作成することができる。第１のステップにおいて、ＮＦ２ＳＬ管理者は、テンプレート・ビルダ・ツール４０３によってテンプレートＸ４００のコンテンツを定式化することができ、かつテンプレートＸ４００をポリシ・エントリ・オブジェクト４０２と関連づけることにより、テンプレートＸ４００をコンテンツベースポリシのサブジェクト・データ・タイプとして指定することができる。

次のステップにおいて、ＮＦ２ＳＬ管理者は、テンプレートＸ４００のｄｓｔ＿ｐｏｒｔフィールド値が８０（「ｈｔｔｐ」）であるかどうかを評価する条件付きオブジェクト４０４を生成することができる。評価が「真」となる場合、テンプレートＸ４００の「ｉｎ＿ｐｋｔｓ」および「ｉｎ＿ｂｙｔｅｓ」フィールドにおいて見出される値は、加算オブジェクト４０５を介して積算器オブジェクト４０６へ転送される。

次のステップにおいて、ＮＦ２ＳＬ管理者は、テンプレートＸ４００の「ｄｓｔ＿ｐｏｒｔ」フィールド値が４４３（「ｈｔｔｐｓ」）であるかどうかを評価する条件付きオブジェクト４０８を生成することができる。評価が「真」となる場合、テンプレートＸ４００の「ｉｎ＿ｐｋｔｓ」および「ｉｎ＿ｂｙｔｅｓ」フィールドにおいて見出される値は、加算オブジェクト４０５を介して積算器オブジェクト４０６へ転送される。条件付きオブジェクト４０４および４０８を生成するに当たって、ＮＦ２ＳＬ管理者は、条件付きオブジェクトビルダ４０７を利用することができる。

次のステップにおいて、ＮＦ２ＳＬ管理者は、テンプレートＸ４００の「ａｐｐ＿ｔａｇ」フィールドがディレクトリサービスに関連づけられる値を含んでいるかどうかを評価する条件付きオブジェクト４０９を生成することができる。評価が「真」となる場合、レコードは転送され、４１０においてさらに処理される。

条件付きオブジェクト４０９の基準を満たすもの以外のレコードは全て、さらなる処理を受けず、４１１においてドロップされる。

このような例示的な時間ベースのポリシは１０秒毎に実行されることが可能であって、ＮｅｔＦｌｏｗテンプレートＹ４０１に対応するＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードを発する。図９ａをさらに参照すると、ＮｅｔＦｌｏｗテンプレートＹ４０１は、次のような例示的フィールドを含む。

ｉｎ＿ｐｋｔｓ−フローにおいて観察されるパケットの累積数

ｉｎ＿ｂｙｔｅｓ−フローにおいて観察されるバイトの累積数

時間ベースのポリシ４１２は、呼び出されると、積算器オブジェクト４０６内に見出される値を検索して、カウンタ４１４の値をリセットする。次に、時間ベースのポリシ４１２は、ＮｅｔＦｌｏｗテンプレート４０１に対応するデータレコードをフォーマットし、これを４１０におけるさらなる処理のために転送する。

ＮＦ２ＳＬポリシ：トラフィックスパイクの検出および報告

図９ｂは、ＮＦ２ＳＬ管理者により指定されるネットワークホストを確かめるためにトラフィック内のスパイクを報告する、例示的なＮＦ２ＳＬポリシモジュールを示す。

ＮＦ２ＳＬのこの例示的なポリシモジュールのコンテンツベースポリシは、シスコシステムズの予め定義された「オリジナル入力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４４０を採用し、かつ条件付きオブジェクト４４１を用いて、レコード４４０のｄｓｔ＿ｉｐ＿ａｄｄｒフィールドが監視されているＩＰアドレス４４２のリストに存在するＩＰアドレスを含むかどうかを決定する。監視されているＩＰアドレスのリストにそのＩＰアドレスが見つかれば、ｉｎ＿ｂｙｔｅｓフィールドのコンテンツがコレクタオブジェクト（収集オブジェクト）４４３内に見出される対応するエントリへ追加され、レコードは転送されて、４４９においてさらに処理される。監視されているＩＰアドレスのリストにそのＩＰアドレスが見つからなくても、レコードは転送されて、４４９でさらに処理される。

ＮＦ２ＳＬシステムは、ＮＦ２ＳＬのこの例示的なポリシモジュールの時間ベースポリシ４４４を、予め定義された間隔、例えば１０秒間隔で呼び出してもよい。ポリシは、呼び出されると、コレクタオブジェクト４４３内のエントリを１つずつ調査し、４４５において、最後の収集間隔の間に観察されたネットワークデバイスへのトラフィック量を抽出する。次に、時間ベースのポリシ４４４は、４４６においてコレクタオブジェクト４４３におけるエントリをリセットする。

時間ベースポリシ４４４の条件付きオブジェクト４４７が、平均的なトラフィック量に比較して、観察間隔中のそのネットワークＩＰアドレスへのトラフィックレートはＮＦ２ＳＬ管理者が述べる尺度で（例えば、１０倍）増加していることを発見すれば、時間ベースのポリシ４４４は、ＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードを生成しかつこれを「Ａｌｅｒｔ：Ｓｐｉｋｅ」定義４４８に従ってフォーマットし、かつこのレコードをさらなる処理のために転送してもよい。

ＮＦ２ＳＬポリシ：内部ネットワーク上のコンプロマイズドホストの検出

図９ｃは、内部ネットワーク上のコンプロマイズされたネットワークホストについてネットワーク管理者に警告する、ある例示的なＮＦ２ＳＬポリシモジュールを示す。このポリシモジュールは、内部ネットワーク上の非サーバであるネットワークホストによる、外部ネットワークのエンティティが行なう要求されていない接続への応答の発生を監視する。高い蓋然性を有するこのようなイベントは、問題の非サーバであるネットワークホストがコンプロマイズされていて、悪意のある外部エンティティに制御されている場合があることを指す。

第１に、ＮＦ２ＳＬのこの例示的なポリシモジュールのコンテンツベースポリシは、シスコシステムズの予め定義された「オリジナル入力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４４０を採用し、かつ条件付きオブジェクト４６１を用いて、レコード４４０のｄｓｔ＿ｉｐ＿ａｄｄｒフィールドが監視されているＩＰアドレス４６２のリストに存在するＩＰアドレスを含むかどうかを決定する。監視されているＩＰアドレスのリストにそのＩＰアドレスが見つかれば、ｄｓｔ＿ｉｐ＿ａｄｄｒ、ｄｓｔ＿ｐｏｒｔ、ｓｒｃ＿ｉｐ＿ａｄｄｒおよびｓｒｃ＿ｐｏｒｔフィールドのコンテンツがコレクタオブジェクト４６３に入れられ、レコードは転送されて、４４９においてさらに処理される。監視されているＩＰアドレスのリストにそのＩＰアドレスが見つからなくても、レコードは単に転送されて、４４９でさらに処理される。

第２に、ＮＦ２ＳＬのこの例示的なポリシモジュールのコンテンツベースポリシは、シスコシステムズの予め定義された「オリジナル出力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４６０を採用し、かつ条件付きオブジェクト４６４を用いて、レコード４６０のｓｒｃ＿ｉｐ＿ａｄｄｒ、ｓｒｃ＿ｐｏｒｔ、ｄｓｔ＿ｉｐ＿ａｄｄｒおよびｄｓｔ＿ｐｏｒｔフィールドがコレクタオブジェクト４６３内に存在するかどうかを決定する。レコード４６０のｓｒｃ＿ｉｐ＿ａｄｄｒ、ｓｒｃ＿ｐｏｒｔ、ｄｓｔ＿ｉｐ＿ａｄｄｒおよびｄｓｔ＿ｐｏｒｔフィールドがコレクタオブジェクト４６３内に存在していなければ、レコードは単に転送されて、４６９でさらに処理される。レコード４６０のｓｒｃ＿ｉｐ＿ａｄｄｒ、ｓｒｃ＿ｐｏｒｔ、ｄｓｔ＿ｉｐ＿ａｄｄｒおよびｄｓｔ＿ｐｏｒｔフィールドがコレクタオブジェクト４６３内に存在していれば、第２のポリシは、内部ネットワークホストと外部エンティティとの間で観察される通信に関する情報を含む「Ａｌｅｒｔ：Ｔｒａｆｆｉｃ」ＮｅｔＦｌｏｗレコード４６５を生成してフォーマットし、かつ４６６におけるさらなる処理のためにこれを転送する。また、これは、このエントリをマッチしたものとしてマーキングしてもよい。また、「オリジナル出力」レコード４６０は、４６９におけるさらなる処理のために転送される場合もある。

ＮＦ２ＳＬシステムは、ＮＦ２ＳＬのこの例示的なポリシモジュールの時間ベースポリシ４６６を、予め定義された間隔、例えば６０秒間隔で呼び出す。時間ベースのポリシ４６６は、コレクタオブジェクト４６３内のエントリにアクセスし、かつ条件付きオブジェクト４６７を用いてコレクタオブジェクト内のエントリがマッチしないかどうかを評価し、かつ６０秒より古いマッチしないエントリをコレクタオブジェクト４６３から除去してもよい。

ＮＦ２ＳＬポリシ：「ローアンドスロー」ネットワークスキャンの検出

ターゲットネットワークのスキャンは、任意の高度なサイバー攻撃の第一段階であることが多い。侵入者は、ネットワークのスキャンを用いてネットワーク上のアクティブなホストを識別する。ネットワークをスキャンしながら、攻撃者は、インターネット上でアクセス可能な固有のＩＰアドレス、そのオペレーティングシステム、システムアーキテクチャおよび各コンピュータ上で実行されるサービスに関する情報を見つける。

所謂「ローアンドスロー」スキャンは、検出しにくいことで悪名高い。攻撃者は、ターゲットのホストまたはネットワークのスキャンに何日も、何週間もかけ、または何か月もかける場合すらある。このスキャン技術により、攻撃者は、そのプローブをネットワークノイズに混和させることができ、検出しきい値を超えたり、一般的な侵入検知システムのリソースを使い果たすことは絶対にない。

ＴＣＰ／ＩＰ ＦＩＮパケットのネットワークスキャンは、最も洗練された走査技術の１つである。ＴＣＰ／ＩＰプロトコルの性質に起因して、ＦＩＮパケットは、その目的を修正することなくファイアウォールを通過することができる。要求されていないＦＩＮパケットに応答して、閉鎖ポートは適切なＲＳＴパケットで返答するが、開放ポートは、漂遊するＦＩＮパケットを無視する。

図９ｄは、最小限のＮＦ２ＳＬシステムおよび他のネットワークリソースを消費しながらローアンドスロースキャンを試行する潜在性についてネットワーク管理者に通知することができる、ＮＦ２ＳＬの例示的なポリシモジュールを示す。

第１に、ＮＦ２ＳＬのこの例示的なポリシモジュールのコンテンツベースポリシは、シスコシステムズの予め定義された「オリジナル入力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４４０を採用し、かつ条件付きオブジェクト４８１を用いて、フローがＴＣＰ／ＩＰフラグＦＩＮセットを有する単一のパケットより成っているかどうかを決定する。この条件の評価が「真」であれば、「オリジナル入力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４４０のｓｒｃ＿ｉｐ＿ａｄｄｒ、ｓｒｃ＿ｐｏｒｔ、ｄｓｔ＿ｉｐ＿ａｄｄｒ、ｄｓｔ＿ｐｏｒｔおよびｔｃｐ＿ｆｌａｇフィールドは、コレクタオブジェクト４８２内に保存され、レコードは、４４９におけるさらなる処理のために転送される。条件の評価が「偽」であれば、レコードは単に転送されて、４４９においてさらに処理される。

第２に、ＮＦ２ＳＬのこの例示的なポリシモジュールのコンテンツベースポリシは、シスコシステムズの予め定義された「オリジナル出力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４６０を採用し、かつ条件付きオブジェクト４８３を用いて、フローがＴＣＰ／ＩＰフラグＲＳＴセットを有する単一のパケットより成っているかどうかを決定する。この条件の評価が「真」であれば、「オリジナル出力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４６０のｄｓｔ＿ｉｐ＿ａｄｄｒ、ｄｓｔ＿ｐｏｒｔ、ｓｒｃ＿ｉｐ＿ａｄｄｒ、ｓｒｃ＿ｐｏｒｔおよびｔｃｐ＿ｆｌａｇフィールドがコレクタオブジェクト４８２内のエントリとマッチングされる。マッチングするエントリが位置決めされれば、「オリジナル出力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４６０および「オリジナル入力」ＮｅｔＦｌｏｗ ＤａｔａＦｌｏｗレコード４４０のｔｃｐ＿ｆｌａｇフィールドが論理的にＯＲされ、レコードは、４４９におけるさらなる処理のために転送される。マッチングするエントリが位置決めされなければ、レコードは単に転送されて、４４９においてさらに処理される。

ＮＦ２ＳＬシステムは、ＮＦ２ＳＬのこの例示的なポリシモジュールの時間ベースポリシ４８４を、予め定義された間隔、例えば６時間間隔で呼び出す。時間ベースのポリシ４８４は、４８５において各レコードを検索し、かつ４８６においてこれをコレクタオブジェクト４８２から除去し、４８７においてレコードを「Ｉｎｆｏ：Ｆｉｎ ｓｃａｎ」ＮｅｔＦｌｏｗテンプレート４８８のフォーマットで出力する。「Ｉｎｆｏ：Ｆｉｎ ｓｃａｎ」ＮｅｔＦｌｏｗテンプレート４８８フォーマットの出力レコードは、４８９におけるさらなる処理のために転送される。

ＮＦ２ＳＬポリシ：ネットワーク監視

ネットワーク監視は、最新のネットワーク監視システム（ＮＭＳ）の基本コンポーネントである。ネットワーク管理者にとって、正確なネットワークトポロジー、各ネットワークデバイスの調子または状態、様々なネットワークセグメント上のトラフィック負荷、様々なアプリケーションによるネットワーク帯域幅の消費、他を知ることは必須である。

インタフェース状態監視：

図９ｅは、１つまたは複数のネットワークデバイスに渡る１つまたは複数のネットワークインタフェースの調子または状態を監視することができる、ＮＦ２ＳＬの例示的なポリシモジュールを示す。

図９ｅを参照すると、１つまたは複数のネットワーク・デバイス・インタフェースを監視するコンテンツベースのポリシは、「ＡＳ（自律システム）集約スキーム」フローレコード５００のシーケンスを基礎として決定を下す（「報告」）。このポリシは、条件付きオブジェクト５０１を用いて、監視されるインタフェースのリスト５０３に入力インタフェース（「ｉｎｐｕｔ＿ｓｎｍｐ」）が含まれているかどうかを決定する。監視されるインタフェースのリスト５０３にそのインタフェースが存在しなければ、レコード５００は、５０２におけるさらなる処理のために転送される。監視されるインタフェースのリストにそのインタフェースが存在すれば、レコード５００に含まれる、そのインタフェース上で観察されるフローに関するタイミング情報（「ｌａｓｔ＿ｓｗｉｔｃｈｅｄ」）がステータス報告リスト５０４へと伝搬され、レコード５００は、５０６におけるさらなる処理のために転送されてもよい。

さらに図９ｅを参照すると、ある例示的な時間ベースのポリシ５０７は、一定の間隔、例えば６０秒間隔で呼び出されてもよい。このポリシは、５０８においてステータス報告リスト５０４内のエントリを読み取ることができ、条件付きオブジェクト５０９が、予め設定された報告遅延しきい値が超過されていることを検出すれば、時間ベースのポリシ５０７は、カスタム情報のフローレコード「インタフェースダウン」５１０を生成し、これは、５１１におけるさらなる処理のために転送される。

帯域幅消費の監視：図９ｆは、１つまたは複数のソフトウェアアプリケーションによるネットワーク帯域幅の消費を監視することができるＮＦ２ＳＬの例示的なポリシモジュールを示す。

図９ｆを参照すると、１つまたは複数のソフトウェアアプリケーションによるネットワーク帯域幅の消費にアクセスするコンテンツベースのポリシは、予め定義されたシスコシステムズの「プロトコルポート」フローレコード５２０を利用する。このポリシは、条件付きオブジェクト５２１を用いて、追跡されるアプリケーションのリスト５２３にアプリケーション（入トラフィックの場合は「１４＿ｄｓｔ＿ｐｏｒｔ」、出トラフィックの場合は「１４＿ｓｒｃ＿ｐｏｒｔ」で定義される）が含まれているかどうかを決定する。追跡されるアプリケーションのリスト５２３にそのアプリケーションが存在しなければ、レコード５２０は、単に転送されて５２２においてさらに処理されてもよい。追跡されるアプリケーションのリストにそのアプリケーションが存在すれば、フロー内で観察される、かつレコード５２０に含まれるパケット（「ｉｎ＿ｐｋｔｓ」）およびバイト（「ｉｎ＿ｂｙｔｅｓ」）の数に関する情報が、アプリケーション集約データリスト５２４内の個々の情報と合計され、次に、レコード５２０は、５２６におけるさらなる処理のために転送されてもよい。

さらに図９ｆを参照すると、ある例示的な時間ベースのポリシ５２７は、一定の間隔、例えば６０秒間隔で呼び出されてもよい。このポリシは、５２８においてアプリケーション集約データリスト５２４内のエントリを読み取り、かつ任意のエントリまたは各エントリについて、カスタム情報のフローレコード「集約アプリケーションデータ」５３０を作成し、かつ５３２においてエントリをリセットしてもよい。作成されたカスタム情報のフローレコード「集約アプリケーションデータ」５３０は、次に、５３１におけるさらなる処理のために転送されてもよい。

ＮｅｔＦｌｏｗエクスポータがネットワークベースのアプリケーション認識（ＮＢＡＲ）メカニズムを装備していれば、上述のポリシが、カスタマイズされた「プロトコルポート」フローレコードにおいて報告されるアプリケーション分類情報（「ａｐｐｌｉｃａｔｉｏｎ＿ｔａｇ」）を利用するように増強される可能性もあり、よってアプリケーション帯域幅消費のより高い細分性が達成されることは認識されるべきである。
本発明の一実施形態によりサポートされることが可能な追加の例示的ポリシには、下記が含まれる：

リンク監視によるアプリケーションプロトコル当たりのネットワークトラフィック

このポリシモジュールの一実施形態は、フローがそれを介してネットワークデバイスに出入りするネットワークデバイスの入出インタフェースに関する情報を含むＮｅｔＦｌｏｗメッセージを入力し、かつフロー分類情報、フロー内で観察されるバイトおよびパケット計数およびフローの始まりと終わりに関するタイミング情報を生成することができる。各ＮｅｔＦｌｏｗエクスポータまたはＮｅｔＦｌｏｗエクスポータの選択されたコンビネーションについて、このポリシモジュールは、アプリケーションプロトコルおよびインタフェースペア（インタフェースの組）当たりのパケット数およびバイト数を合計することができる。

監視されるプロトコルのリストが含まれてもよく、また、リストは設定可能であってもよい。監視リストに含まれていない全てのアプリケーションプロトコルは、「その他」と明記されるプロトコルの下で合計されてもよい。アプリケーションプロトコルは、ＯＳＩレイヤ３プロトコル（例えば、ＴＣＰ）、ＯＳＩレイヤ４宛先ポート（例えば、ポート８０−ｈｔｔｐ）、ＯＳＩレイヤ７の分類子（例えば、ＰＡＮＡ−Ｌ７等の分類子エンジンＩＤ、これに続くこの分類におけるベンダー指定のアプリケーションＩＤ）、または他の任意のネットワークトラフィック分類スキーマとして解釈されてもよい。

ネットワークインタフェースは、ペアで１つのリンクを構成する。リンク内のインタフェースは、その個々のＳＮＭＰインデックス（ｉｎｐｕｔ＿ｓｎｍｐおよびｏｕｔｐｕｔ＿ｓｎｍｐ）によって識別されてもよい。リンクの数は、ランタイムで決定されても、設定により所定のインタフェースサブセットに制限されても、ハードコードされてもよい。概して、観察されるリンクの数に制限はない。ポリシモジュールは、設定可能な時間期間（期間）における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、所定のカウンタを基礎とする集約された報告を発してもよく、トラフィック毎に興味深い各リンクトラバーサルを報告してもよい。

このポリシモジュールの利用により配信できる情報は、ネットワークマネージャにより、下記毎のバイトまたはパケット数を含む、但しこれらに限定されないネットワークトラフィックの詳細をリアルタイムで見るために使用されることが可能である。

ある特定のネットワークデバイス

このネットワークデバイスの１つのリンク

あるアプリケーションプロトコル

選択された１つのネットワークデバイスについて、ネットワークマネージャは、各リンク内のアプリケーションプロトコル毎の、または各アプリケーションプロトコル内のリンク毎のネットワークトラフィックの組成を見ることができる。また、ネットワークマネージャは、あるリンクを介するトラフィックがいつになく多くなるイベント、またはある所定のリンク上のパケットサイズが大幅に縮小するイベントを見分ける場合もある。後者のイベントは、ハードウェアの機能不全を示す場合も、サイバー攻撃の兆候である場合もある。

このポリシモジュールにより生成されるデータは、例えばネットワークトラフィックをより使用量が多いネットワーク部分からより少ないネットワーク部分へ移動させることによるネットワーク規模の負荷バランシング、アプリケーション識別情報から導出されるコンテンツベースのルーティング、および他の類似する目的のために制限なしに使用されることが可能である。このデータのさらに別の使用法は、概して、ネットワークのトラフィック調査および容量プランニングである。

プロトコル毎のトップホスト接続の識別

このポリシモジュールの一実施形態は、接続ホストのソースおよび宛先ＩＰアドレスに関する情報を含むＮｅｔＦｌｏｗメッセージを入力し、かつ観察される各ホストにより行われる接続の数を合計することによって、ある時間期間（期間）に渡る最もアクティブ（活動的）なホストのリストを生成する。アクティブなホストのリストは、所定の期間に渡って観察された全てのホスト、最もアクティブなＮ個のホスト（「上位Ｎ個の接続」）によるグループ、または他の何らかの基準に従って選択されたホストによるグループを含んでもよい。

ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の基準を基礎とする集約された報告を発してもよい。

このポリシモジュールの利用により配信可能な情報は、ネットワークマネージャにより、ある特定の時間期間に渡って最も多くの接続を開始しているホストを識別するために使用されることが可能である。この情報は、ウイルスまたはワームまたはｅメールスパムを拡散する感染したホストを示している可能性がある。

上位ホストトーカの識別

このポリシモジュールの一実施形態は、通信ネットワークホストのソースおよび宛先ＩＰアドレスに関する情報を含むＮｅｔＦｌｏｗメッセージを入力し、かつ観察される各ホストにより送られるバイト数およびパケット数を合計して、予め定義された時間期間に渡る最もアクティブなホストのリストを生成する。

監視されるプロトコルのリストが含まれてもよく、また、リストは設定可能であってもよい。監視リストに含まれていない全てのアプリケーションプロトコルは、「その他」と明記されるプロトコルの下で合計されてもよい。アプリケーションプロトコルは、ＯＳＩレイヤ３プロトコル（例えば、ＴＣＰ）、ＯＳＩレイヤ４宛先ポート（例えば、ポート８０−ｈｔｔｐ）、ＯＳＩレイヤ７の分類子（例えば、ＰＡＮＡ−Ｌ７等の分類子エンジンＩＤ、これに続くこの分類におけるベンダー指定のアプリケーションＩＤ）、または他の任意のネットワークトラフィック分類スキーマとして解釈されてもよい。

アクティブなホストのリストは、所定の期間に渡って観察された全てのホスト、最もアクティブなＮ個のホスト（「上位Ｎトーカ」）によるグループ、または他の何らかの基準に従って選択されたホストによるグループを含んでもよい。

ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする集約された報告を発してもよい。ポリシモジュールは、全体として最も高いトラフィックの生成者を対象とするタイプ、および最も多くのパケットを生成したホストを対象とする別のタイプ等の、複数のメッセージタイプを生成することができる。

このポリシモジュールの利用により配信可能な情報は、ネットワークマネージャにより、ＤｏＳまたは低量ＤｏＳサイバー攻撃を示すパターン、全体的な負荷バランシング、トラフィック調査および容量プランニングを目的としてネットワークトラフィックを分析するために使用されることが可能である。

この規則の追加的な利点は、ネットワークデバイスによっては上位ホストトーカの報告を設定できるものもあるが、これをＮＦ２ＳＬにおいて設定すれば、ＮＦ２ＳＬに接続される全てのネットワークデバイス上にこれが即座に効果的に設定されることにある。

エッジデバイスのアクセス制御違反の監視

このポリシモジュールの一実施形態は、ネットワークのエッジデバイス上のイベントに関する情報を含む、ＮｅｔＦｌｏｗメッセージおよびシスコＡＳＡのＮｅｔＦｌｏｗセキュリティイベント言語（ＮＳＥＬ）等のその派生メッセージを入力する。ある例示的な実施形態において、ＮＦ２ＳＬは、シスコＡＳＡのＮＳＥＬメッセージを入力し、かつセキュリティイベントに関連する、ＮＳＥＬ ＮＦ＿Ｆ＿ＦＷ＿ＥＶＥＮＴフィールド等のフィールドにおいて情報を処理する。このようなフィールドにおいて報告される値を評価することにより、ＮＦ２ＳＬは、全ての、または選択されたネットワークポリシの違反者を特定し、かつある時間期間に渡って最も多い違反を有するホスト（上位Ｎ）のリストを生成することができる。ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする報告を発してもよい。監視されるエッジデバイスがＡＡＡシステム（例えば、マイクロソフトのアクティブディレクトリ、ＲＡＤＩＵＳ、他）に統合されていれば、報告は、ネットワークポリシ違反者のユーザｉｄを含んでもよい。エッジデバイスにそうした情報を生成する能力がある場合、報告は、違反された正確なポリシに関する情報を含んでもよい（即ち、分岐ＡＣＬを識別する）。

このポリシモジュールの利用により配信可能な情報は、ネットワークマネージャにより、異常な挙動を示すホストを識別し、かつ不適切なアクティビティに関わるユーザを識別するために使用されることが可能である。これは、悪者または感染したホストを示すものである可能性もある。さらに、違反されたネットワークポリシに関する情報を実際のエッジデバイス設定情報と相関することにより、ネットワークマネージャは、違反者にとって関心対象がどのリソースであったかを発見する場合があり、必要であれば、組織のセキュリティ姿勢を調整してもよい。

ＤＮＳサーバの挙動監視

このポリシモジュールの一実施形態は、ホストとＤＮＳサーバとの間のネットワークトラフィックに関する情報を含むＮｅｔＦｌｏｗメッセージを入力し、かつＤＮＳサーバの平均応答時間およびある時間間隔に渡る交換パケットの平均サイズを計算することができる。ポリシは、選択されたサーバのリストについて、または観察される全てのＤＮＳサーバについて、平均応答時間および平均パケットサイズを報告することができる。ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする報告を発してもよい。

このポリシモジュールは、周知のＯＳＩレイヤ４ポート番号（例えば、ポート８０上のｈｔｔｐサーバ）によって、またはＯＳＩレイヤ７分類子（例えば、アプリケーション識別子を伴うＰＡＮＡ−Ｌ７）によって特徴づけられる任意のネットワークサービスへ拡張されてもよい。

このポリシの利用により配信可能な情報は、ネットワークマネージャにより、ＤＮＳ応答時間が長くなる場合のＤＮＳサービスに関連する問題点を識別するために使用されることが可能である。ＤＮＳサービスは、エンドユーザへのコンテンツ配信を有効化することから、広範囲に分布されるネットワークを通じて最高レベルの利用可能性および最短の応答時間を提供しなければならない。ビジネス活動に対するＤＮＳの役割の重要性に起因して、セキュリティ攻撃はＤＮＳサーバを標的にすることが多く、これをトラフィックで溢れさせて障害発生時点にまで至らせ、サービスの中断を狙う。ＤＮＳサービスの応答時間の鈍化は、破壊的な攻撃が進行中であることを示す場合がある。よって、ネットワークマネージャは、防護措置を講じて、そのローカルホストのＤＮＳ要求を他のＤＮＳサーバへリルートしてもよい。

さらに、ＤＮＳサーバとＤＮＳサービス要求者とで交換される平均パケットサイズを調べることにより、ネットワークマネージャは、ＤＮＳサービスが妨害されているかどうかを識別してもよい。例えば、ＤＮＳサービスの応答パケットサイズの増大は、ＤＮＳサーバを妨害して、ＤＮＳサービス要求者を標的にバッファのオーバーフロー攻撃を行なう試みを示す場合がある。

また、ＤＮＳサービスにより提供される、後続のホスト通信に反映される次のホップ（次に経由する中継装置）の情報を調査して、ＤＮＳサービスにより示唆されるルーティング経路の大幅な変化に留意することにより、このポリシがＤＮＳ改変者のマルウェア等の悪意のあるアクティビティを識別する場合があることも認識される。

リンク当たりの平均パケットサイズの監視

このポリシモジュールの一実施形態は、ネットワークトラフィックに関する情報を含むＮｅｔＦｌｏｗメッセージを入力して、ある時間間隔に渡る１対のネットワーク・デバイス・インタフェース（「リンク」）を通過したネットワークパケットの平均サイズを計算することができる。ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする報告を発してもよい。

このポリシの利用により配信可能な情報は、ネットワークマネージャにより、ネットワークのボトルネックまたは悪意のあるアクティビティを特定するために使用されることが可能である。パケットサイズの想定外の低下（パケット破砕）は、機能不全のハードウェアまたは進行中のサイバー攻撃を示している可能性もある。さらに、この情報をネットワーク上のサーバから入手される情報と相関することにより、ネットワークマネージャは、情報配信問題がネットワーク上から生じているか、サーバによる下手なパフォーマンスによるものかを識別してもよい。健全なネットワークであれば、確実に、そのサーバを問題のある者として識別する。後者の場合、ネットワーク管理者は、パフォーマンス不良のアプリケーションを識別して、是正措置を講じてもよい。

アプリケーションプロトコル毎のリンク当たり平均パケットサイズの監視

このポリシモジュールの一実施形態は、ネットワークトラフィックに関する情報を含むＮｅｔＦｌｏｗメッセージを入力して、監視されるアプリケーションプロトコル毎に、ある時間間隔に渡る１対のネットワーク・デバイス・インタフェース（「リンク」）を通過したネットワークパケットの平均サイズを計算することができる。ポリシは、監視されるプロトコル毎の平均パケットサイズを報告することができる。ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする報告を発してもよい。

このポリシの利用により配信可能な情報は、ネットワークマネージャにより、ネットワークのボトルネックまたは悪意のあるアクティビティを特定するために使用されることが可能である。パケットサイズの想定外の低下（パケット破砕）は、機能不全のハードウェアまたは進行中のサイバー攻撃を示している可能性もある。さらに、この情報をサーバから入手される情報と相関することにより、ネットワークマネージャは、情報配信問題がネットワーク上から生じているか、アプリケーションサーバによる下手なパフォーマンスによるものかを識別してもよい。健全なネットワークであれば、確実に、そのアプリケーションサーバを問題のある者として識別する。後者の場合、ネットワーク管理者は、パフォーマンス不良のアプリケーションを識別して、是正措置を講じてもよい。

エッジデバイスの上位帯域幅ユーザの識別

このポリシモジュールの一実施形態は、エッジデバイスを通過するトラフィックに関する情報を含む、ＮｅｔＦｌｏｗメッセージおよびシスコＡＳＡのＮｅｔＦｌｏｗセキュリティイベント言語（ＮＳＥＬ）等のその派生メッセージを入力する。観察される通信を合計することにより、このポリシは、ある時間期間に渡るエッジデバイス帯域幅の上位Ｎ名のコンシューマ（利用者）を識別することができる。コンシューマに関する情報は、通信するネットワークホストのＩＰアドレスとして提供されてもよい。エッジデバイスがＡＡＡシステム（例えば、マイクロソフトのアクティブディレクトリ、ＲＡＤＩＵＳ、他）に統合されていれば、報告は、消費された帯域幅を特定のユーザｉｄに帰してもよい。ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする報告を発してもよい。

このポリシモジュールの利用により配信可能な情報は、ネットワークマネージャにより、エッジデバイスを通るネットワークの最も高位の帯域幅ユーザを識別するために使用されることが可能である。この情報は、従業員による望ましくないネットワーク使用法（例えば、ビデオのストリーミング、過度のインターネットブラウジング、他）、または大規模ファイルのネットワーク内部から無認可の外部ロケーションへの転送を識別するために使用されることが可能である。

さらに、典型的なエッジデバイス配備における高いトラフィック量および流量に起因して、デバイスの帯域幅消費に関する情報は、概して収集されない。この欠陥は、ｓｙｓｌｏｇ生成時のエッジデバイス上の高負荷、およびログ収集およびＳＩＥＭシステムにこのような大量の着信ログを受け入れて使用する能力がないことに起因する。

ＮＦ２ＳＬは、その高いパフォーマンスおよびデータ集約ケイパビリティに起因して、ネットワーク管理者がエッジデバイスの帯域幅消費情報を全体的なネットワーク管理データプールに包含すること、およびネットワーク容量およびセキュリティ姿勢について貴重な洞察を引き出すことを有効化する。

アプリケーションプロトコルによるネットワークデバイス毎のエッジデバイス上位帯域幅ユーザの識別

このポリシモジュールの一実施形態は、エッジデバイスを通過するトラフィックおよびこのようなメッセージを生成させるアプリケーションに関する情報を、このようなアプリケーションが周知のＯＳＩレイヤ４のポート番号（例えば、ポート８０上のｈｔｔｐサーバ）によって、またはＯＳＩレイヤ７分類子（例えば、アプリケーション識別子を伴うＰＡＮＡ−Ｌ７）によって特徴づけられる程度に含む、ＮｅｔＦｌｏｗメッセージ（およびＮｅｔＦｌｏｗ ｖ９、ＩＰＦＩＸ、シスコＡＳＡＮｅｔＦｌｏｗセキュリティイベント言語（ＮＳＥＬ）、パロアルトネットワークスのＮｅｔＦｌｏｗ等のその派生メッセージ）を入力する。観察される通信を合計することにより、このポリシは、特定のアプリケーションについて、ある時間期間に渡るエッジデバイス帯域幅の上位Ｎ名のコンシューマを識別することができる。コンシューマに関する情報は、通信するネットワークホストのＩＰアドレスとして提供されてもよい。エッジデバイスがＡＡＡシステム（例えば、マイクロソフトのアクティブディレクトリ、ＲＡＤＩＵＳ、他）に統合されていれば、報告は、消費された帯域幅を特定のユーザｉｄに帰してもよい。ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする報告を発してもよい。

このポリシモジュールの利用により配信可能な情報は、ネットワークマネージャにより、エッジデバイスを通るネットワークの最も高位の帯域幅ユーザを識別するためと、上位の帯域幅消費アプリケーションを識別するために使用されることが可能である。この情報は、従業員による望ましくないアプリケーション使用法（例えば、裁可されていないアプリケーションの使用）、および内部ホスト上のボットネットスレーブ等のマルウェアアプリケーションの存在を識別するために使用されることが可能である。

さらに、典型的なエッジデバイス配備における高いトラフィック量および流量に起因して、デバイスの帯域幅消費に関する情報は、概して収集されない。この欠陥は、ｓｙｓｌｏｇ生成時のエッジデバイス上の高負荷、および収集およびＳＩＥＭシステムにこのような大量の着信ログを受け入れて分析する能力がないことに起因する。

ＮＦ２ＳＬは、その高いパフォーマンスおよびデータ集約ケイパビリティに起因して、ネットワーク管理者がアプリケーションベースでエッジデバイスの帯域幅消費情報を全体的なネットワーク管理データプールに包含すること、およびネットワーク容量およびセキュリティ姿勢について貴重な洞察を引き出すことを有効化する。

ネットワークサブネットの監視

このポリシモジュールの一実施形態は、通信するネットワークホストの宛先ＩＰアドレスに関する情報を含むＮｅｔＦｌｏｗメッセージを入力し、かつ観察される各ホストから監視される外部サブネットのリストへ送られるバイト数およびパケット数を合計することができる。このポリシモジュールは、予め定義された時間期間に渡って最も多いトラフィックを有するサブネットのリストを生成することができる。監視されるプロトコルのリストが含まれてもよく、また、リストは設定可能であってもよい。プロトコル監視リストに含まれていない全てのアプリケーションプロトコルは、「その他」と明記されるプロトコルの下で合計されてもよい。アプリケーションプロトコルは、ＯＳＩレイヤ３プロトコル（例えば、ＴＣＰ）、ＯＳＩレイヤ４宛先ポート（例えば、ポート８０−ｈｔｔｐ）、ＯＳＩレイヤ７分類子（例えば、ＰＡＮＡ−Ｌ７等の分類子エンジンＩＤ、これに続くこの分類におけるベンダー指定のアプリケーションＩＤ）、または他の任意のネットワークトラフィック分類スキーマとして解釈されてもよい。

サブネットのリストは、監視される全てのサブネット、最もアクセスされたＮ個のサブネットによるグループ、他の何らかの基準に従って選択されたサブネットによるグループを含んでもよい。

ポリシは、設定可能な時間期間における集約された結果の報告を有効化する時間ベースのトリガを含んでもよく、または所定のカウンタまたは他の何らかの基準を基礎とする集約された報告を発してもよい。ポリシモジュールは、全体として最も高いトラフィックの受信者を対象とするタイプ、および最も多くのパケットを受信したサブネットを対象とする別のタイプ等の、複数のメッセージタイプを生成することができる。

このポリシモジュールの利用により配信可能な情報は、ネットワークマネージャにより、内部ホストと、クラウドベースのリソース専用のもの等のリモートサブネットとの間のネットワークトラフィックを分析し、各リモートサブネットへのトラフィック量およびトラフィックパターンを決定し、かつリモートリソースを最適な方式で運用するために使用されることが可能である。

挙動ベースのネットワーク監視

このポリシモジュールの一実施形態は、少なくとも２つの動作モード、即ち学習および監視、を行なうことによって、「オーバーベースライン（基準超過）」ポリシを実装する。学習モードは、ネットワークトラフィックのベースライン（基準）情報を集めるためにオンにされることが可能である。監視モードは、オペレーションの学習期間中に入手される情報を用いて、ネットワーク状態を監視する。これらの２つの動作モードは排他的ではなく、学習プロセスは、監視がオンにされている間も継続してもよい。

学習モードが動作している状態で、ポリシは、ベースライン情報を収集し、かつこれを、例えばローカルデータベース（例えば、ＮＦ２ＳＬの一部として提供されるもの）等の永続性記憶装置に記憶することができる。ベースライン情報は、短い時間間隔、例えば５分間に渡るトラフィック挙動を統合したものであってもよい。学習される挙動の情報が広がることによって、ベースライン（基準）ポリシは、時刻、曜日および何月かにも依存して、トラフィックのパターンを考慮することができる。時間ベースのトラフィックパターンの他に、ベースライン挙動には、以下のトラフィックパターンが含まれる。

− 同時フローの数

− グローバルなパケットレート

− グローバルなスループット

− プロトコル当たりのスループット

− 新規フローの作成速度

− 送受信されるＴＣＰ／ＩＰ ＳＹＮパケットの数

− ＴＣＰ／ＩＰ接続リセットの数

− フローの平均持続時間

− フロー持続時間の分散

− リモートサブネットの利用

− ＶＬＡＮの利用度

− グローバルアプリケーションの組成

− その他。

トラフィックパターンの上述のリストが網羅的ではなく、よってベースライン（基準）挙動の計算には他のトラフィック特性が含まれ得ることは認識される。

ベースライン情報が収集されると、これは、分析およびしきい値の定義のために表計算等のツールへ移出される可能性もある。あるいは、ベースラインポリシは、正常なトラフィックパターンからの偏向を決定するために内蔵メカニズムを実装することができる。

しきい値の設定に当たっては、望ましければ３段式手法、即ち、予測、警告および破断点、が利用されてもよい。しきい値が、マニュアル式に決定されても、統計分析から導出されても、ファジーな挙動モデルに嵌め込まれてもよいことは認識される。

しきい値は、好ましくは、ポリシオペレーションの監視モードがオンにされる前に設定される。監視モードがオンにされると、ポリシは、現行で観察される挙動を、対応するしきい値モデルを用いるベースライン情報と比較することができる。しきい値が超過されると、例えばｓｙｓｌｏｇメッセージまたはｅメールであるアラートメッセージが生成されて、ネットワーク監視アナリストへ警告するためにネットワークマネージャまたはＳＩＥＭシステムへ直に送信されてもよい。

ベースラインポリシは、さらなる観察を基礎として、またはネットワークマネージャのコマンド等の外部イベントによりトリガされてネットワークのベースライン挙動を調整することにより、適応式に行動してもよい。

このポリシの利用により配信可能な情報は、ネットワークマネージャにより、悪意のあるソフトウェアに感染したホストによって引き起こされる、または悪者によって引き起こされる異常なネットワークアクティビティをタイムリーに検出するために使用されることが可能である。

ボットネットアクティビティの検出

ボットネットスレーブは、伝統的なホストベースおよびネットワークベースの手段では検出が困難であるとして悪名高い。ボットネットスレーブは、しばしば、ホスト内部からは検出できないルートキットとして自らをインストールすることによって、ホストベースのメカニズムによる検出を回避する。ボットネットスレーブの伝統的なネットワークベース検出は、膨大な量の情報収集、およびボットネットスレーブのビーコンを探す広範な科学捜査に依存する。これらの問題点は、ネットワーク情報をストリーミング式に処理するシステムを使用することによって克服されてもよい。

ボットネットアクティビティを検出するポリシモジュールの一実施形態は、内部ネットワーク上の「立入禁止」デバイスが外部のピア（なお、「ピア」とは、ある通信プロトコルでデータを交換する2台の装置の対のこと）に応答するイベントを識別することができる。内部ネットワーク上のホストは、概して、外界への接続（例えば、ウェブブラウジング）を開始してもよいが、接続が外部から開始される場合のこのトラフィックへの応答は、内部ネットワーク上にボットネットスレーブが存在していることを示す可能性がある。

このポリシモジュールの一実施形態は、通信するネットワークホストの宛先ＩＰアドレスに関する情報を含むＮｅｔＦｌｏｗメッセージを入力して、これらのＩＰアドレスを、構成された監視される立入禁止ネットワークデバイスのリストと比較する。そのＩＰアドレスがリストに存在しなければ、対策は講じられない。宛先ＩＰアドレスが監視されるデバイスのリストに見出されれば、ソースＩＰアドレスおよび宛先ＯＳＩレイヤ４ポート、ならびに宛先ＩＰアドレスおよびソースＯＳＩレイヤ４ポートが、バイトおよびパケット計数、他等の他の情報と共に、潜在的アラート（潜在的な警告）のリストに格納される。また、アプリケーションプロトコル情報も、潜在的アラートのリストに記入される場合がある。このコンテキストでは、プロトコル情報は、ＯＳＩレイヤ３プロトコル（例えば、ＴＣＰ）、ＯＳＩレイヤ４宛先ポート（例えば、ポート８０−ｈｔｔｐ）、ＯＳＩレイヤ７分類子（例えば、ＰＡＮＡ−Ｌ７等の分類子エンジンＩＤ、これに続くこの分類におけるベンダー指定のアプリケーションＩＤ）、または他の任意のネットワークトラフィック分類スキーマとして解釈されてもよい。

次のステップにおいて、ポリシモジュールは、接続開始者に対して、監視される立入禁止内部デバイスから応答があったかどうかを監視する。このような通信が予め設定された期間内に行われれば、ポリシモジュールは、ｓｙｓｌｏｇ、ｅメール、他等の標準的な通信プロトコルのうちの１つを用いて対応するメッセージを送信することによって、ネットワークマネージャまたはＳＩＥＭシステムに警告する。予め設定された応答時間期間が経過すれば、ポリシは、この立入禁止デバイスを潜在的アラートのリストから除去することができる。

デバイスが潜在的アラートのリストに含まれる時間間隔は、変わってもよい。このステップは、ボットネット監視システムに気づいていて、応答を遅らせることで検出を回避しようとするボットネット通信を捕捉できるようにする。

ボットネット検出ポリシモジュールの別の実施形態は、内部ネットワークホストのＩＰアドレス、その通信ピアおよびこれらの通信の間に利用されるプロトコルに関する情報を含むＮｅｔＦｌｏｗメッセージを入力する。このコンテキストでは、プロトコル情報は、ＯＳＩレイヤ３プロトコル（例えば、ＴＣＰ）、ＯＳＩレイヤ４宛先ポート（例えば、ポート８０−ｈｔｔｐ）、ＯＳＩレイヤ７分類子（例えば、ＰＡＮＡ−Ｌ７等の分類子エンジンＩＤ、これに続くこの分類におけるベンダー指定のアプリケーションＩＤ）、または他の任意のネットワークトラフィック分類スキーマとして解釈されてもよい。

このように、ポリシモジュールは、観察された全ての通信のデータベースを徐々にコンパイルし、これは、普通でない通信の発見を目的として分析されることが可能である。この分析は、大規模なネットワークトラフィックのパターングループをストリーミング式に決定し、かつ外れ値を識別する目的で、ＳＴＲＥＡＭ、ＢＩＲＣＨ、他等のデータ・ストリーミング・クラスタリング方法を用いて実行される可能性もある。小さく「正常でない」クラスタの存在は、確実に、ボットネット通信の特徴である異常なネットワークアクティビティを示している。このような異常なクラスタが発見されれば、ポリシモジュールは、ｓｙｓｌｏｇ、ｅメール、他等の標準的な通信プロトコルのうちの１つを用いて対応するメッセージを送信することにより、ネットワークマネージャまたはＳＩＥＭシステムに警告することができる。

観察される全ての通信のデータベースにおける普通でない通信の発見が、他の類型的データ分析方法によって、またはクラスタリング計算値をオフラインで求めることにより静的に実行され得ることは認識される。

このポリシの利用により配信可能な情報は、ネットワークマネージャにより、ネットワーク上のボットネットスレーブをタイムリーかつ費用効果的な方法でを識別して根絶するために使用されることが可能であるが、これは、大部分が無関係のデータである特大のデータベースを収集しかつこれを事後にオフラインで分析することによってネットワークデバイスの感染を発見しようとする現行方法の使用では不可能である。本明細書に開示する技術による、ネットワーク由来のマルウェアをタイムリーに発見することの有用性は、米国連邦通信委員会（ＦＣＣ）により最近普及された規則によって明らかにされている。

会話

このポリシの一実施形態は、ある時間期間Ｔに渡るデバイス間の会話を統合し、かつ上位Ｎ個の会話をＳＩＥＭシステムへ送信することができる。会話は、同じポート（ソースポートおよび宛先ポート）を使用する、同じトランスポート（ＴＣＰまたはＵＤＰ）上の、同じルータ／スイッチ（エクスポータ）を通過する２つのホスト（ソースＩＰおよび宛先ＩＰ）間の相互作用の結果として生成される一連のＮｅｔＦｌｏｗメッセージとして定義される。これらのフローのバイトおよびパケットの数は、定義された時間期間に渡って合計され、かつ統合されたｓｙｓｌｏｇまたは他のフォーマットのメッセージ内に押し出されることが可能である。この技術は、下流側のＳＩＥＭシステムによる収集および／または分析のために送信されるマシンデータの量を大幅に低減する１つの方法として使用されることが可能である。

レピュテーションを基礎とする警告

このポリシの一実施形態は、通信するには安全でないとみなされる、ネットワークデバイスを出入りして流れるネットワークトラフィックを検出することができる。ネットワークデバイスを安全でないと分類する基準は、そのＩＰアドレスまたは完全修飾識別名（ＦＱＤＮ）の何れかによって識別されるネットワークデバイスの公開されていて入手可能なデータベースまたは私的データベースを基礎としてもよい。例えば、エイリアンヴォールトは、フィッシング攻撃、マルウェアの拡散、ボットネットマスタ、他に関わっていることが知られるネットワークデバイスの公開されていて入手可能なデータベースを提供している。デバイスは、レピュテーションと呼ばれる、その予想される有害さのレベルに従ってランク付けされる。例えば、既知のボットネットマスタと通信する危険性は、フィッシングホストへの接続より高位にランク付けされる。

この実施形態によるポリシは、外部デバイスから、このような安全でないＩＰアドレスまたはＦＱＤＮのリストを受信することができ、または、このようなリストの提供者に直に照会して、保護されているネットワーク上のネットワークデバイスと、安全でないデバイスのリスト上のネットワークデバイスとの間の通信の発生を報告する。ポリシは、通信行為および接触された外部ネットワークデバイスのレピュテーションレベルを示す警告をタイムリーに発行することができる。

所定の国からのトラフィック

所定の国は、産業スパイおよびサイバー戦争行為を行っていることが知られている。このポリシの一実施形態は、このような国に存在するネットワークデバイスから内部ネットワークデバイスへの通信、および内部ネットワークデバイスからこのような国におけるホストへの通信を追跡する。ＩＰアドレスレンジの国別リストは、インターネット割り当て番号機関（ＩＡＮＡ）から公開されていて入手可能である。ポリシは、このようなリスト、またはこのようなリストのサブセットを用いて、外部ネットワークデバイスの通信元である国を決定し、かつこのような通信の行為をタイムリーに報告する。

ＯＳＩレイヤ３のプロトコル

ネットワーク利用の監視は、企業および電気通信プロバイダにとって極めて重要である。このような環境におけるアプリケーションデータのほとんどは、ＵＤＰ（ＯＳＩレイヤ３プロトコルｉｄ１７）およびＴＣＰ／ＩＰ（ＯＳＩレイヤ３プロトコルｉｄ６）上で伝送される。これらの「働き者」であるプロトコルの他に、ネットワークの保全に関連する大量の通信が存在する。例えば、ＩＣＭＰ（インターネット制御メッセージプロトコル）プロトコル（ＯＳＩレイヤ３プロトコル１）は、ネットワークデバイスのステータスの検証、ネットワークルートのトレース、他を目的とするメッセージを含む。ＩＣＭＰおよび、ＩＳＩＳ、ＥＧＰ、ＲＳＶＰ、その他のような他の類似するユーティリティプロトコルに関連づけられるネットワークパケットは、ネットワークトラフィック全体におけるかなりの割り当て分を構成する。ネットワーク上には、かなりの制御トラフィックが存在することから、電気通信プロバイダは、このようなトラフィックの絶え間ない監視を必要とする。

このポリシの一実施形態は、ＴＣＰおよびＵＤＰ以外のＯＳＩＬ３プロトコルを介して転送されている制御トラフィックに関する情報を収集する。ポリシは、全てのＯＳＩレイヤ３プロトコルを追跡しても、監視されるべきＯＳＩレイヤ３プロトコルの設定されたリストを用いてもよい。ＩＣＭＰ等のプロトコルによっては、ポリシは、伝送されるデータの所定の特有のサブタイプのみを追跡するように構成されてもよい。例えば、裁可されていないネットワークデバイスによって発行されるリダイレクトＩＣＭＰパケットの追跡は、ネットワーク上の破壊的なアクティビティ（動作、流れ）を明示するものとなる場合がある。

ポリシのさらに別の実施形態は、制限された通信を監視するように構成される。例えば、ＧＲＥプロトコルは、任意の非ＩＰトラフィックをＩＰネットワーク上で伝送するように設計される。このＧＲＥケイパビリティは、ＧＲＥカプセル化されなければネットワーク・セキュリティ・インフラによって検出されるはずの違法トラフィックをマスクするために使用される場合がある。ポリシは、ＧＲＥカプセル化されたネットワークフローを監視し、前記フローのソースＩＰアドレスが合法的なＧＲＥトラフィックソースのリストに存在するかどうかをチェックし、かつこの合法的ソースリストに含まれていないネットワークデバイスにより試行される通信をタイムリーに報告する。

上述のポリシの実施形態が共に、単一のポリシモジュールにおいて実装される可能性もあれば、複数のポリシモジュールにおいて実装される可能性もあることは認識される。

集約（統合）されたトラフィック

このポリシの一実施形態は、宛先ネットワークサブネットおよびネットワークサブネットマスクのリストを使用し、かつローカル・ネットワーク・デバイスによりこのようなサブネットへ送信されるバイト数と、このようなサブネットによりローカルホストへ送信されるバイト数とを合計する。このポリシは、ネットワークマネージャに、クラウドベースの私的データセンタ等のリモートリソースの利用に対する貴重な洞察を提供することができる。

トラフィック量が増加するにつれて、ＮｅｔＦｌｏｗコレクタ等の伝統的な手段では、本明細書に記述する方法によるネットワーク帯域幅利用の測定がもはや不可能であることは認識される。この問題は、最新のネットワークデバイスにより発せられるＮｅｔＦｌｏｗトラフィックのレートが極端に高いことから生じる。例えば、シスコＡＳＲ１０００等の８０Ｇｂｐｓミドルレンジルータは、毎秒４００，０００フローまでを処理して報告することができる。受信するＮｅｔＦｌｏｗレコードを後続処理のために保存する超ハイエンドのＮｅｔＦｌｏｗコレクタであっても、メッセージをこのようなレートで処理することはできず、毎秒１００，０００レコードの壁に到達することはほとんどない。このような高いレートが持続される可能性があるのは、ＮｅｔＦｌｏｗ処理がストリーミング式に行われる場合に限られる。

このポリシのさらに別の実施形態は、内部ネットワークの利用に対する洞察を与える。この実施形態において、ポリシは、サブネットＩＰアドレスおよびＩＰアドレスマスクではなく、ＶＬＡＮ当たりのネットワークトラフィック情報を集約する。

インタフェースのリアルタイム利用

ネットワークのパフォーマンスおよび信頼性は、今日の企業およびサービスプロバイダ組織における最も重要な要素である。全てのネットワークコンポーネントが適切に機能していることを確認し、かつ問題を可能な限り最短で検出することは重要である。

このポリシの一実施形態は、あるネットワーク・デバイス・インタフェースを通過するトラフィックを集約し、かつネットワークパケットのドロップおよび全体的な輻輳を引き起こし得るインタフェース容量の利用不足またはインタフェース利用レベルが高くなりすぎる場合を通知する。インタフェースは、そのＳＮＭＰインデックスによって識別されてもよい。インタフェースのタイプおよび容量は、ネットワークデバイスにより発せられるＮｅｔＦｌｏｗオプションＦｌｏｗＳｅｔから推測される。インタフェース利用のしきい値は、マニュアル式に指定される可能性もあれば、統計分析から導出される、またはファジーな挙動モデルに嵌め込まれる可能性もある。

このポリシが、単一のインタフェースまたは複数のインタフェースの利用を追跡し得ることは認識される。

ＮｅｔＦｌｏｗの重複排除

ＮｅｔＦｌｏｗの重複排除は、「重複する」ＮｅｔＦｌｏｗレコードをなくすための技術である。ネットワーク状態に対する完全な可視性を得るために、多くの組織は、全てのネットワークデバイス上のＮｅｔＦｌｏｗを有効化している。ネットワークパケットは、あるホストから別のホストへ移動するにつれて複数のルータおよびスイッチを通り、これらの各々が、同じネットワークフローを表すＮｅｔＦｌｏｗレコードを生成する。重複するフローに関する情報の包含は、結果的にトラフィック量の計算を不正確にし、またはセキュリティイベントの重要性を誤って伝える場合がある。さらに、記憶装置およびソフトウェアのライセンシングコストが著しく高まる結果ともなる可能性がある。

このポリシの一実施形態は、ソースＩＰ−宛先ＩＰホストペア毎の信頼できるエクスポータの動的選択を基礎とするフローの重複排除を実装することができる。

ある例示的な実施形態において、このポリシは、ソースＩＰアドレス、宛先ＩＰアドレス、ネットワーク上で見えるＮｅｔＦｌｏｗエクスポータおよびあるエクスポータがＩＰアドレスで識別される通信するエンドポイントペア間の通信を最後に報告した時間による４次元行列をメモリに埋め込んで保持する。ＮｅｔＦｌｏｗレコード等のフロー記述を受信すると、ポリシは、受信したフロー記述において見出されるそのエクスポータが観察したエンドポイント間のフローの計数を更新する。観察されたフローの現行の最大数（「重量」）を有するエクスポータは、信頼できるエクスポータとして指定され、集計にはそのフローレポートのみが計上される。

動的なフロー行列において２名以上のエクスポータが同じ重量を有していれば、この不確定さは、例えば、各エクスポータが同じフローを報告した相対時間を比較することによって解決されることが可能である。そのフローをより早い時間に報告したエクスポータは、所定の通信エンドポイントに対してもう一方のエクスポータより上流に位置づけられることから、信頼できるエクスポータとして指定される。ポリシは、例えば、各エクスポータが報告した地方時間をその固有の時間に正規化し（「クロックスキュー」）、かつそのようなクロックスキューを基礎としてフロー観察の相対時間を計算することによって、エクスポータの相対時間を計算することができる。ルーティング経路の曖昧さは、さらに、例えばフロー記述レコードにおいて報告される次のホップ（次に経由する中継装置）のＩＰアドレスを調べることによってなくされてもよい。あるいは、概してフロー記述において報告される残り寿命（ＴＴＬ）の値は、報告側エクスポータ間のフロートラバーサル順序を示し、かつこれらの目的で使用されてもよい。

また、任意の所定時間において、本方法は、ネットワークの現行のルーティングトポロジーのスナップショットを提供することもできる。このネットワークトポロジーは、この情報をエンドユーザに提示することができるエンティティへ、グラフィカルに、テキストテーブルの形式で、二次元マップで、または他の手段で報告されることが可能である。

ポリシのこの実施形態は、重要な値のネットワークマネージャへの提供を、ネットワーク帯域幅消費の正確な計数を動的に提供することによって行なうことができる。この情報のタイムリーな配信は、フローコレクタのデータベースからの検索等の伝統的な手段による実行といった事後的な様式ではなく、ストリーミング式に報告される場合にのみ可能である。さらに、フロー情報のストリーミング式重複排除は、フロー情報の重複をフローコレクタのデータベースへの保存後に排除するために使用され得る、伝統的なフローコレクタには必要な記憶装置の必要性を大幅に減らす。

ＮＦ２ＳＬコンバータ

ＮＦ２ＳＬコンバータは、概してＮｅｔＦｌｏｗデータＦｌｏｗＳｅｔレコードを取り、ＮＦ２ＳＬ管理者が指定するマッピングに従ってｓｙｓｌｏｇメッセージを生成する。図９Ｘは、ＮＦ２ＳＬ ＧＵＩベースの変換ツール４３１を用いる、例示的なＮｅｔＦｌｏｗテンプレートＦｌｏｗＳｅｔ４２０のＳｙｓｌｏｇメッセージ４２１へのマッピングを示す。

ＮＦ２ＳＬ管理者は、ＮｅｔＦｌｏｗテンプレートからのＳｙｓｌｏｇメッセージを、ＮｅｔＦｌｏｗテンプレートＦｌｏｗＳｅｔ４２０内のフィールド記述子をドラッグしかつこれらを変換ツール４３１のキャンバス上へドロップすることによってフォーマットすることができる。例えば、ｉｐｖ４＿ｓｒｃ＿ａｄｄｒおよび１４＿ｓｒｃ＿ｐｏｒｔフィールド４２２、およびｉｐｖ４＿ｄｓｔ＿ａｄｄｒおよび１４＿ｄｓｔ＿ｐｏｒｔフィールド４２３は、変換ツール４３１のキャンバス上に置かれている。同様にして、ＮＦ２ＳＬ管理者は、ｉｎ＿ｐｋｔｓフィールド４２４をマップすることもできる。

結果的に生じる例示的なＳｙｓｌｏｇメッセージ４２１は、ＮｅｔＦｌｏｗ生成者のタイムスタンプ４２５と、ＮｅｔＦｌｏｗ生成者のＩＰアドレス４２６と、ＮｅｔＦｌｏｗ生成者のＮｅｔＦｌｏｗソースＩＤ４２７と、フローソースのＩＰアドレスおよびソースポート４２８と、フロー宛先のＩＰアドレスおよび宛先ポート４２９と、フロー内で観察されたパケット数４３０とから成る。

ストリーミングシステムのケイパビリティの一般化

ＮＦ２ＳＬシステムは、本発明の例示的な一実施形態である。ネットワークメタデータを複数のフォーマットで受信し、このように受信されるネットワークメタデータを１つまたは複数のポリシに従って処理しかつ場合により変換し、このように処理されたネットワークメタデータを複数のフォーマットに変換しかつ変換されたネットワークメタデータをリアルタイムで中継することができる、というこの開示しているストリーミングシステムの概念は、他の実用的なアプリケーションに拡張される可能性もあることは認識される。

例えば、図１０を参照すると、ストリーミングシステムは、スイッチまたはルータ等のＮｅｔＦｌｏｗを生成するＯｐｅｎＦｌｏｗ準拠デバイス２８０を通って流れるトラフィックを管理するＯｐｅｎＦｌｏｗコントローラ２８２の能力を増強するために使用されてもよい。

ＯｐｅｎＦｌｏｗ準拠デバイス２８０上のＮｅｔＦｌｏｗ生成者２８５は、あるポートを通過する、またはフロー内で観察されるトラフィックの量だけでなく、そのフローを正確にはどのアプリケーションがインスタンス化したのかに関する情報および他の追加情報をも示すＮｅｔＦｌｏｗプロトコルメッセージ２８３を発するように構成されてもよい。トラフィックの量およびその起源（発生源）に関するこの増強された情報は、次に、ストリーミングシステムのＮｅｔＦｌｏｗ−ＯｐｅｎＦｌｏｗ（ＮＦ２ＯＦ）２８１によってダイジェストされ、かつポート統計、フロー統計および個々のフロー統計またはその類似物等の拡張されたＯｐｅｎＦｌｏｗプロトコルメッセージ２８４を介してＯｐｅｎＦｌｏｗコントローラ２８２へ送られてもよい。

本発明のこの態様は、アプリケーションレベルのサービス品質（ＱｏＳ）要件に対する洞察を与えることにより、一般的なＯｐｅｎＦｌｏｗコントローラのネットワーク管理ケイパビリティをより高度に洗練されたレベルにまで引き上げる。

支払いカード業界のデータセキュリティ基準（ＰＣＩ−ＤＳＳ）、２００２年度施行の連邦情報セキュリティ管理法（ＦＩＳＭＡ）、サーベンス・オクスリー法（ＳＯＸ）、医療保険の相互運用性と説明責任に関する法律（ＨＩＰＡＡ）、他等の規制遵守要件に起因して、組織は、イベント、システム構成、ネットワークのトラフィックおよびパフォーマンスを含む広範なセキュリティ関連データを継続して監視しかつ報告しなければならない。この要件の主要部分は、ログの収集および保存である。ログの収集は、Ｓｙｓｌｏｇメッセージの搬送にＵＤＰを用いるｓｙｓｌｏｇプロトコルの損失しがちな性質に起因して、困難なタスクであることが分かっている。

図１１を参照すると、本発明の一実施形態は、ログ配信を確実にする目的で使用されてもよい。この実施形態において、ＳＬ２ＡＳＬ（確実なｓｙｓｌｏｇへのｓｙｓｌｏｇ）システム３０３は、コンピューティングデバイス３００上に存在するｓｙｓｌｏｇ生成者３０１に近接して配備される。ＳＬ２ＡＳＬシステムをネットワークメタデータ生成者に近接して配備することにより、ネットワークメタデータを損失するリスクは最小限に抑えられる。

この実施形態において、ＳＬ２ＡＳＬシステム３０３は、受信されるｓｙｓｌｏｇプロトコルメッセージ３０２を、標準的なｓｙｓｌｏｇプロトコルメッセージ３０４の配信ＵＤＰトランスポートを用いて複数のｓｙｓｌｏｇコンシューマデバイス３０５に複製する。この技術は、ログ情報を確実に保存する確率を高める。

図１１をさらに参照すると、さらに別の実施形態において、ＳＬ２ＡＳＬシステム３０３は、受信されるｓｙｓｌｏｇプロトコルメッセージ３０２を高信頼性のＴＣＰ／ＩＰ接続部３０６上へ送信することにより、拡張型ｓｙｓｌｏｇコンシューマデバイス３０８と通信してもよい。キープアライブチャネル３０７は、拡張型ｓｙｓｌｏｇコンシューマ３０８が故障した場合に、ＳＬ２ＡＳＬシステム３０３がローカル輻輳制御ファシリティ（設備、装置）を用いて、拡張型ｓｙｓｌｏｇコンシューマデバイス３０８が再起動する間にｓｙｓｌｏｇプロトコルメッセージ３０２を一時的に蓄積することを保証する。

本発明のこの実施形態は、ログ収集の規制遵守要件の履行を大幅に単純化する。

本発明の一実施形態は、ＮｅｔＦｌｏｗ情報をＷＡＮ上でリモートネットワークから中央ネットワークへ確実に配信するために使用されてもよい。

図１１ａを参照すると、ある典型的なブランチ６０１の配備において、ＮｅｔＦｌｏｗ有効化ルータ６０３は、ブランチネットワーク６０２上のＮｅｔＦｌｏｗ情報６０６を収集し、ＮｅｔＦｌｏｗ情報６０６をＷＡＮ６０４上で、ＨＱ６００に配備されるルータ６０５を介してＮｅｔＦｌｏｗコレクタ６０７へ伝送する。

しかしながら、ブランチ６０１とＨＱ６００との間のＮｅｔＦｌｏｗ情報６０６の移送に使用されるＵＤＰプロトコルの信頼性のなさに起因して、伝送されるＮｅｔＦｌｏｗ情報６０６の一部は伝送中に失われることがあり、その結果、ＮｅｔＦｌｏｗコレクタ６０７には不完全なＮｅｔＦｌｏｗ^＊情報６０８が届くことになる。

ＳＣＴＰ等の高信頼性または準信頼性トランスポートプロトコルの使用は、高信頼性トランスポートプロトコルでは処理できないＮｅｔＦｌｏｗ有効化ルータ６０３上の高いＮｅｔＦｌｏｗイベント率に起因して望ましくない場合が多い。このような場合、ネットワーク管理者は、サンプリングされたＮｅｔＦｌｏｗレポートに頼ることを余儀なくされ、よってネットワークメタデータの希薄さがさらに増す。

図１１ｂを参照すると、ここではＮＦ２ＡＳＬ（確実なＳｙｓＬｏｇへのＮｅｔＦｌｏｗ）と称される本発明の一実施形態は、ＮｅｔＦｌｏｗ情報６０６の高い伝送率をサポートする間のＮｅｔＦｌｏｗ情報６０６の伝送中の損失を防止する。

図１１ｂをさらに参照すると、ＮｅｔＦｌｏｗ有効化ルータ６０３は、ブランチネットワーク６０２上のＮｅｔＦｌｏｗ情報６０６を収集し、かつＮｅｔＦｌｏｗ情報６０６をＮＦ２ＡＳＬサーバ６２０へ伝送する。ＮｅｔＦｌｏｗ有効化ルータ６０３およびＮＦ２ＡＳＬサーバ６２０は互いに近接して配備されることから、ＮｅｔＦｌｏｗ情報６０６の損失は存在しないか、ごく僅かである。ＮＦ２ＡＳＬサーバ６２０は、ＮｅｔＦｌｏｗ情報６０６を受信すると、これをｓｙｓｌｏｇ情報６２１に変換する。変換プロセスは、ＮＦ２ＡＳＬサーバ６２０上に配備される１つまたは複数のポリシおよび変換規則に従って、またはデフォルトの変換規則に従って実行されてもよい。

ＮｅｔＦｌｏｗ情報６０６のＨＱ６００への配信の信頼性を最大限に高めるために、ＮＦ２ＡＳＬサーバ６２０は、ｓｙｓｌｏｇ情報６２１を複製してＨＱ６００に配備される複数のｓｙｓｌｏｇサーバ６２２へ送るように構成される。複製されたｓｙｓｌｏｇ情報６１２は、ＷＡＮ６０４上をＨＱ６００に配備されるルータ６０５へ配信される。

ｓｙｓｌｏｇ情報６２１を複製することにより、ＮＦ２ＡＳＬサーバ６２０は、ＮｅｔＦｌｏｗ情報６０６を保存する確率を高める。ＮｅｔＦｌｏｗ情報６０６が保存される確率が、ｓｙｓｌｏｇ情報６２１の複製先であるｓｙｓｌｏｇサーバ６２０の数に伴って高まることは予想される。

図１１ｃを参照すると、本発明の一実施形態は、仮想マシンハイパーバイザ３１２がその制御下の仮想マシンの組成を管理する能力を増強するために使用されてもよい。

ＮｅｔＦｌｏｗ生成者３１５は、仮想マシンハイパーバイザ３１２を実行しかつそのアプリケーションにこのトラフィックが属するサーバ３１０を宛先とするトラフィックの量を示すＮｅｔＦｌｏｗプロトコルメッセージ３１３を発するように構成されてもよい。トラフィック量およびその意味的組成に関する情報は、ストリーミングシステム３１１のハイパーバイザへのＮｅｔＦｌｏｗ（ＮＦ２ＨＶ）によってダイジェストされ、かつ情報プロトコルメッセージ３１４に入れてサーバ３１０上で実行される仮想マシンハイパーバイザ３１２へ渡されてもよい。

本発明のこの態様は、仮想マシンハイパーバイザ３１２が、サーバ３１０上で実行されるミッションクリティカルなアプリケーションに必要なリソースを提供するためにリアルタイムのネットワーク負荷および組成情報を用いることを可能にする。

図１２を参照すると、本発明の一実施形態は、多様なｍ名のネットワークメタデータ生成者３２１および多様なｎ名のネットワーク・メタデータ・コンシューマ３２４を有する環境で用いるためにさらに一般化されてもよい。

システムの例示的な実施形態ｍＸ２ｎＹ３２０が、ネットワークメタデータを送信するためにネットワークメタデータ生成者３２１によって使用される複数の入力プロトコル３２２を見分けることができる点は認識されるべきである。例えば、ネットワークメタデータ生成者３２１の中には、ＮｅｔＦｌｏｗプロトコルメッセージを発するものもあれば、ｓｙｓｌｏｇを介してネットワークメタデータを伝達するものもある。

ネットワークメタデータを含むメッセージを受容可能なフォーマット３２２のうちの１つで受信すると、システムの実施形態ｍＸ２ｎＹ３２０は、このメッセージを、そのメッセージの入力フォーマット用に構成される１つまたは複数のポリシへ内的にディスパッチすることができる。ポリシアプリケーションの結果は、複数の出力プロトコル３２３上で１つまたは複数のネットワーク・メタデータ・コンシューマ３２４へ転送されてもよい。

図１３は、システムの実施形態ｍＸ２ｎＹ３２０の例示的な内部組成を示す。この例では、所定のタイプの入力プロトコルメッセージ３２２が専用のレシーバモジュールＲＸ３４１によって受信され、入力プロトコルメッセージ３２２はレシーバモジュールＲＸ３４１によって専用のフォーマッタモジュールＦ３４２へ転送される。フォーマッタモジュールＦ３４２は、入力プロトコルメッセージ３２２を、ポリシモジュールＰ３４３により理解される共通のネットワーク・メタデータ・フォーマットに変換することができる。次に、フォーマッタモジュールＦ３４２は、変換された入力プロトコルメッセージ３２２をポリシモジュールＰ３４３へ送ることができ、ポリシモジュールＰ３４３は、設定されたポリシの適用に当たって、入力プロトコルメッセージ３２２を任意の派生ネットワークメタデータと共にディスパッチャモジュール３４４へ転送することができる。ディスパッチャモジュール３４４は、出力プロトコルメッセージ３２３をコンバータモジュール３４５へ配分するように構成されることが可能であり、コンバータモジュール３４５は、出力プロトコルメッセージ３２３を、ネットワーク・メタデータ・コンシューマへ転送するために送信モジュール３４６へ送ることができる。

システムの例示的な実施形態ｍＸ２ｎＹ３２０の内部組成が、上述の組成とは異なる場合のあることは認識されるべきである。例えば、複数のフォーマット用モジュール３４２は、単一の汎用フォーマットモジュール、他として実装される可能性もある。

また、図１３をさらに参照すると、システムの実施形態ｍＸ２ｎＹ３２０のインスタンスは、ネットワークメタデータ３２２をシステムの実施形態ｍＸ２ｎＹ３２０の他のインスタンスから受信するように配備される場合があることも認識されるべきである。同様に、システムの実施形態ｍＸ２ｎＹ３２０のインスタンスは、ネットワークメタデータの処理の結果３２３をシステムの実施形態ｍＸ２ｎＹ３２０の他のインスタンスへ転送するように配備される場合があることは認識されるべきである。

本発明を幾つかの実施形態に関連して説明したが、本発明の範囲に含まれる変形、変更、置換、および代替均等物が存在する。本発明の説明を補助するために、小項目のタイトルを付しているが、これらは単に例示的なものであって、本発明の範囲を限定するためのものではない。

また、本発明の方法および装置の実装に当たっては、多くの代替方法が存在することも留意されるべきである。したがって、添付した下記の請求の範囲は、このような変形、変更、置換および代替均等物を全て本発明の真の精神および範囲内にあるものとして包含すると解釈されるべきものである。

Claims (80)

1. ネットワーク上で生成されネットワークトラフィックを送信するネットワークメタデータを１つまたは複数のネットワークプロトコルを用いて処理する方法であって、前記ネットワークは、そのうちの少なくとも幾つかが入力インタフェースを介してネットワークトラフィックを受信しかつ出力インタフェースを介してネットワークトラフィックを送信する複数のデバイスを含み、前記方法は、
   データ処理システムにおける複数のソースからネットワークメタデータを少なくとも１つのデータフォーマットで受信するステップと、
   前記ネットワークメタデータのタイプまたは特徴を決定するステップと、
   有益な情報を抽出するために前記ネットワークメタデータを処理するステップと、
   少なくとも部分的に前記決定するステップの結果に応じて、前記ネットワークメタデータの少なくとも一部を、前記データ処理システムにおいて他のシステムメタデータ用に使用される１つまたは複数の異なるデータフォーマットに変換するステップとを含む方法。
2. 前記処理するステップは、前記ネットワークメタデータが、前記ネットワーク上で前記ネットワークメタデータを生成したネットワークデバイスと前記ネットワークメタデータを格納することができるデバイスとの間を移行する間に実行される、請求項１に記載の方法。
3. 前記処理するステップは、ネットワークメタデータ処理を統率する少なくとも１つのポリシを適用することによって達成される、請求項２に記載の方法。
4. 前記少なくとも１つのポリシは、セキュリティに対する潜在的脅威であることを示す前記ネットワーク上のトラフィックを検出する目的で適用される、請求項３に記載の方法。
5. 前記少なくとも１つのポリシは、
   着信するネットワークトラフィックのソースを、前記ネットワーク上の監視される立入禁止デバイスの予め定義されたリストと比較するステップと、
   宛先ＩＰアドレスが立入禁止デバイスの予め定義されたリストに存在すれば、潜在的アラートリストにソースＩＰ／ポートならびに宛先ＩＰ／ポートを、入力側のＮｅｔＦｌｏｗレコードに報告されているバイトおよびパケットの数と共に格納するステップと、
   前記ソースＩＰ／ポートおよび前記宛先ＩＰ／ポートが前記潜在的アラートリスト内のエントリに一致するかどうかを決定するために、出力レコードを調べるステップと、
   一致が発見されれば、このような一致を、内部ホストが外部ピア要求に応答したことを示すものとして扱うステップと、
   ボットネット感染の可能性を知らせるアラートメッセージをタイムリーに生成するステップとを含む、請求項４に記載の方法。
6. 前記少なくとも１つのポリシは、
   外部ネットワークデバイスと通信する内部ネットワークデバイスに関する情報を収集するステップであって、前記情報は、通信しているデバイスのＩＰアドレスおよびプロトコルのリストを含むステップと、
   前記通信するデバイス間の通信におけるパターンを決定するために、ストリーミングクラスタ分析法を適用するステップと、
   計算された全パターンの集合における、小さく分解されたパターンの存在により、前記通信するデバイス間の通信の異常なインスタンスを識別するステップと、
   少なくとも１つの異常な通信パターンが識別されれば、ボットネット感染の可能性を知らせるアラートメッセージをタイムリーに生成するステップとを含む、請求項４に記載の方法。
7. 前記少なくとも１つのポリシは、前記ネットワーク上のトラフィックスパイクを識別する目的で適用される、請求項３に記載の方法。
8. 前記少なくとも１つのポリシは、
   着信するネットワークトラフィックのソースを、前記ネットワーク上の監視されるデバイスの予め定義されたリストと比較するステップと、
   ソースＩＰアドレスがデバイスの予め定義されたリストに存在すれば、メモリ内データベースにソースＩＰを、入力側のＮｅｔＦｌｏｗレコードに報告されているバイトおよびパケットの数と共に格納するステップと、
   予め定義された間隔で、前記メモリ内データベースを調べて、ネットワークマネージャが規定するしきい値を超えるデバイスを識別するステップと、
   トラフィックスパイクを知らせるアラートメッセージをタイムリーに生成するステップとを含む、請求項７に記載の方法。
9. 前記少なくとも１つのポリシは、前記ネットワーク上のＮｅｔＦｌｏｗトラフィックを捕捉する信頼性を高める目的で適用される、請求項３に記載の方法。
10. 前記少なくとも１つのポリシは、
    信頼性がないネットワーク・トランスポート・プロトコル上で１つまたは複数のＮｅｔＦｌｏｗメッセージを受信するステップと、
    場合により、前記受信されたＮｅｔＦｌｏｗメッセージを、ＮｅｔＦｌｏｗ以外のフォーマット、異なる特徴のＮｅｔＦｌｏｗまたは前記受信されるＮｅｔＦｌｏｗと同じフォーマットのうちの１つまたはそれ以上に変換するステップと、
    前記受信された、または変換されたメッセージを、信頼性がないネットワーク・トランスポートプロトコル上で複数のエンドポイントへ、信頼性のあるネットワーク・トランスポート・プロトコル上で少なくとも１つのエンドポイントへ、または信頼性がないネットワーク・トランスポートプロトコル上で少なくとも１つのエンドポイントへ、かつ信頼性のあるネットワーク・トランスポート・プロトコル上で少なくとも１つのエンドポイントへ転送するステップとを含む、請求項９に記載の方法。
11. 前記少なくとも１つのポリシは、前記ネットワーク上の前記ネットワークメタデータを格納するデバイスに到着するＮｅｔＦｌｏｗメッセージの数を減らす目的で適用される、請求項３に記載の方法。
12. 前記少なくとも１つのポリシは、
    複数のＮｅｔＦｌｏｗメッセージを受信するステップと、
    前記受信されたＮｅｔＦｌｏｗメッセージにおける類似性を識別するステップと、
    前記受信されたＮｅｔＦｌｏｗメッセージにおける類似するとして識別された情報を、１つまたは複数のＮｅｔＦｌｏｗメッセージに統合するステップと、
    情報を統合されたＮｅｔＦｌｏｗメッセージを廃棄するステップと、
    統合されたＮｅｔＦｌｏｗメッセージを、前記ネットワーク上のネットワークメタデータを格納するデバイスへ転送するステップとを含む、請求項１１に記載の方法。
13. 前記統合されたＮｅｔＦｌｏｗメッセージを転送するステップは、設定可能な時間期間の経過後に実行される、請求項１２に記載の方法。
14. 前記少なくとも１つのポリシは、前記ネットワーク上のネットワークインタフェースが動作不能になる時点を検出する目的で適用される、請求項３に記載の方法。
15. 前記少なくとも１つのポリシは、
    着信するネットワークメタデータにおけるインタフェース識別子の不在が前記ネットワークインタフェースの動作不能状態を示す間のしきい値時間期間を確立するステップであって、前記確立されるしきい値時間期間は、時間および地理的基準に依存して可変であるステップと、
    前記ネットワークインタフェースに関連するネットワークメタデータを監視するステップと、
    前記ネットワークインタフェースに関連するネットワークメタデータが前記しきい値時間期間を超える期間に渡って検出されなければ、前記ネットワークインタフェースの動作不能状態を知らせるアラートメッセージをタイムリーに生成するステップとを含む、請求項１４に記載の方法。
16. 前記少なくとも１つのポリシは、前記ネットワーク上のネットワークメタデータを用いてネットワーク待ち時間を測定する目的で適用される、請求項３に記載の方法。
17. 前記少なくとも１つのポリシは、
    ドメイン名サーバ（ＤＮＳ）のサービスを要求したネットワークデバイスがその間に前記ＤＮＳサービスから応答を受信しなければならないしきい値時間期間を確立するステップと、
    ネットワークデバイスとＤＮＳサービスとの間の通信を規定するネットワークメタデータを監視するステップと、
    前記ネットワークデバイスによるＤＮＳサービスの要求と、このＤＮＳサービスからの応答の受信との間の経過時間を計算するステップと、
    前記経過時間を前記しきい値時間期間と比較するステップと、
    過度のネットワーク待ち時間を知らせるアラートメッセージを生成するステップとを含む、請求項１６に記載の方法。
18. 前記少なくとも１つのポリシは、前記ネットワーク上の複数のデバイスに渡って、アプリケーションタイプ別にリアルタイムのネットワーク可視性を提供する目的で適用される、請求項３に記載の方法。
19. 前記少なくとも１つのポリシは、前記ネットワーク上で特定の時間期間に渡って最も活動的なホストのリストを生成する目的で適用される、請求項３に記載の方法。
20. 前記少なくとも１つのポリシは、
    複数のネットワーク・メタデータ・メッセージを受信するステップと、
    個々のネットワークホストに関連するネットワークメタデータを識別するステップと、
    識別された各ネットワークホストについて、ネットワークメタデータを集約するステップと、
    最も多くのネットワーク接続を生成したネットワークホストのサイズ設定可能リストを選択するステップと、
    最も多くのネットワーク接続を生成した前記ネットワークホストのリストを報告するステップとを含む、請求項１９に記載の方法。
21. 前記少なくとも１つのポリシは、特定の時間期間に渡ってアクセス制御リストに最も多く違反したネットワーク上のデバイスのリストを生成する目的で適用される、請求項３に記載の方法。
22. 前記少なくとも１つのポリシは、
    ネットワークメタデータを含む複数のメッセージを受信するステップであって、前記メタデータは、アクセス制御リストの違反に関する情報を含むステップと、
    各メッセージが少なくとも１つのアクセス制御リスト違反を報告するように、前記メッセージのサブセットを選択するステップと、
    報告されたネットワークデバイス毎に前記メッセージのサブセットを集約するステップと、
    アクセス制御リストに最も多く違反したネットワークデバイスがリストの最初にくるように、前記集約されたメッセージのサブセットを降順に並び替えるステップと、
    前記ソートされたリストの冒頭から設定可能なエントリ数を検索するステップと、
    前記リストの冒頭における前記エントリにおいて見出される、アクセス制御リストに最も多く違反したネットワークデバイスを知らせるアラートメッセージをタイムリーに生成するステップとを含む、請求項２１に記載の方法。
23. 前記少なくとも１つのポリシは、指定可能な時間間隔に渡って、指定可能な入力インタフェースおよび出力インタフェースを介してネットワークデバイスを通過するネットワークパケットの平均サイズを計算する目的で適用される、請求項３に記載の方法。
24. 前記少なくとも１つのポリシは、
    ネットワークメタデータを含む複数のメッセージを受信するステップであって、前記メタデータは、区別可能な入力インタフェースと区別可能な出力インタフェースとの間を通ったパケット数およびバイト数に関する情報を含むステップと、
    前記情報を、区別可能なインタフェースペア毎に集約するステップと、
    区別可能な各インタフェースペアを通過したネットワークパケットの現行の平均サイズを計算するステップと、
    前記区別可能なネットワークインタフェースペアの少なくとも一部同士の間を通ったネットワークパケットの平均サイズに関する情報を、タイムリーに報告するステップとを含む、請求項２３に記載の方法。
25. 前記少なくとも１つのポリシは、指定可能な時間間隔に渡るネットワーク帯域幅の上位の利用者であるネットワーク上のデバイスを識別する目的で適用される、請求項３に記載の方法。
26. 前記少なくとも１つのポリシは、
    複数のネットワーク・メタデータ・メッセージを受信するステップと、
    個々のネットワークホストに関連するネットワークメタデータを識別するステップと、
    識別された各ネットワークホストについて、ネットワークメタデータを集約するステップと、
    最も多くのネットワークトラフィックを生成したネットワークホストのサイズ設定可能リストを選択するステップと、
    最も多くのネットワークトラフィックを生成した前記ネットワークホストのリストを報告するステップとを含む、請求項２５に記載の方法。
27. 前記少なくとも１つのポリシは、指定可能な時間間隔に渡る、ネットワークデバイス毎、ネットワークプロトコル毎のネットワーク帯域幅の上位の利用者であるネットワーク上のデバイスを識別する目的で適用される、請求項２６に記載の方法。
28. 前記少なくとも１つのポリシは、このようなアクティビティの基準レベルより上であるネットワーク上のアクティビティを識別する目的で適用される、請求項３に記載の方法。
29. 前記少なくとも１つのポリシは、指定可能な時間期間に渡り、学習モードにおいて、前記ネットワークのマネージャの関心を引くネットワーク状態の特徴に関して正常であると思われるパラメータの基準を確立するように動作するステップと、監視モードにおいて、前記マネージャに、前記ネットワーク上のアクティビティが前記基準を予め定義可能なレベルだけ超過すると報告するように動作するステップとを含む、請求項２８に記載の方法。
30. 前記基準は、
    同時フローの数、グローバルなパケットレート、グローバルなスループット、新規フローの生成レート、送信されるＳＹＮパケットの数、受信されるＳＹＮパケットの数、接続リセットの数、平均フロー持続時間、フロー持続時間の分散および時刻より成るグループからの１つまたは複数のネットワーク属性に関連するネットワーク情報を含む、請求項２９に記載の方法。
31. 前記少なくとも１つのポリシは、フローエクスポータにより報告されるフロー情報の重複を排除する目的で適用される、請求項３に記載の方法。
32. 前記少なくとも１つのポリシは、
    − 通信しているエンドポイントのＩＰアドレスと、フローレコードを提供したデバイスのＩＰアドレスとを含むフローレコードを受信するステップと、
    − 前記レコードが受信された時間を書き留めるステップと、
    − メモリに、通信しているエンドポイントのＩＰアドレス、フロー報告デバイスのＩＰアドレスおよび最後に観察された通信の時間に関する情報を保全するステップであって、前記情報は、少なくとも幾つかの通信路が前記フロー報告デバイスによって利用される頻度を示すものであるステップと、
    − 前記メモリ情報を基礎として、前記フローを報告する他のフロー報告デバイスのうちで最も高い使用頻度を有するフロー報告デバイスを選択し、かつ前記最も高い頻度のフロー報告デバイスを、前記ネットワークエンドポイント間の通信に関する情報の信頼できるソースとして指定するステップと、
    − 前記メモリ情報に反映されている最も高い使用頻度が２つ以上のフロー報告デバイスで同じである場合、さらに、フロー報告デバイスが前記フローを報告した時間、前記フロー報告デバイスにより提出されたフローレコードに報告されている残り寿命カウンタ、および前記フロー報告デバイスにより提出されたフローレコードに報告されている次のホップのＩＰアドレスより成るグループから選択される基準に基づいて、前記ネットワークエンドポイント間の通信に関する情報の前記信頼できるソースの同一性の曖昧さをなくすステップと、
    − 前記信頼できるフロー報告デバイスから受信される前記通信しているエンドポイント間の通信に関するフローレコードを、さらなる処理のために転送するステップと、
    − 他のフロー報告デバイスから受信される前記通信しているエンドポイント間の通信に関するフローレコードを廃棄するステップとを含む、請求項３１に記載の方法。
33. 前記少なくとも１つのポリシは、
    前記ネットワークをトラバースするネットワークメタデータから、ＩＰアドレスおよびインタフェースインデックスに関連する隣接性のリストを収集するステップと、
    前記隣接性のリストから、前記ネットワークのデバイスおよびトポロジーを表現するコンピュータモデルを構築するステップと、
    前記ネットワーク上の特定のネットワーク・トラフィック・フローに関連するネットワークメタデータを独自に生み出すデバイスを統計的に識別するステップと、
    下流のネットワークデバイスにより生成され得るネットワークメタデータ情報の重複を、前記下流デバイスを介する同じネットワークトラフィックのフローを反映して排除するステップとを含む、請求項３１に記載の方法。
34. 前記受信されるネットワークメタデータをネットワークメタデータの下流側の利用者またはコレクタへ、その少なくとも１つのデータフォーマットを保全しながら転送するステップをさらに含む、請求項１に記載の方法。
35. 変換されたネットワークメタデータを前記１つまたは複数の異なるデータフォーマットのネットワークメタデータの利用者またはコレクタへ転送するステップをさらに含む、請求項１に記載の方法。
36. 前記決定するステップは、前記受信されるネットワークメタデータの有効性に関連する少なくとも１つのアサーションを追認することを含む、請求項１に記載の方法。
37. 前記変換するステップは、前記受信されるネットワークメタデータを共通のデータフォーマットに変換することを含む、請求項１に記載の方法。
38. 前記決定するステップは、前記ネットワークメタデータに割り当てられる過渡的な識別子の検索を含む、請求項１に記載の方法。
39. ネットワークメタデータの過渡的な識別子は、前記ネットワークメタデータに割り当てられる永続的な識別子に動的に関連づけられる、請求項３８に記載の方法。
40. ネットワークメタデータの永続的な識別子は、さらに１つまたは複数のポリシに関連づけられる、請求項３９に記載の方法。
41. 前記処理するステップは、１つまたは複数のポリシを前記ネットワークメタデータに適用することを含む、請求項４０に記載の方法。
42. 前記決定するステップは、前記ネットワークメタデータを分類することを含む、請求項１に記載の方法。
43. 前記分類するステップは、ネットワークメタデータ処理を統率する少なくとも１つのポリシを適用することによって達成される、請求項４２に記載の方法。
44. 前記少なくとも１つのポリシは、前記ネットワークメタデータのコンテンツを基礎とする、請求項４３に記載の方法。
45. 前記少なくとも１つのポリシは時間ベースである、請求項４３に記載の方法。
46. 前記少なくとも１つのポリシは、動的にロード可能なソフトウェアモジュールを組み入れることによって実装される、請求項４３に記載の方法。
47. 前記動的にロード可能なソフトウェアモジュールはバイナリ実行可能モジュールである、請求項４６に記載の方法。
48. 前記少なくとも１つのポリシの適用は、前記処理されるネットワークメタデータから導出される追加的なネットワークメタデータを生成する、請求項４３に記載の方法。
49. 前記追加的なネットワークメタデータは、前記処理されるネットワークメタデータと同じフォーマットである、請求項４８に記載の方法。
50. 前記追加的なネットワークメタデータは、前記処理されるネットワークメタデータのフォーマット以外のフォーマットである、請求項４８に記載の方法。
51. 前記少なくとも１つのポリシの適用は、ネットワークメタデータのコンテンツを変換する、請求項４３に記載の方法。
52. 前記ネットワークメタデータを変換するステップは、変換規則を適用することを含む、請求項１に記載の方法。
53. 前記変換規則は、前記ネットワークメタデータのコンテンツを基礎とする、請求項５２に記載の方法。
54. 前記変換規則はデフォルトの変換規則である、請求項５２に記載の方法。
55. 前記変換規則は、動的にロード可能なソフトウェアモジュールを組み入れることによって実装される、請求項５２に記載の方法。
56. 前記動的にロード可能なソフトウェアモジュールはバイナリ実行可能モジュールである、請求項５５に記載の方法。
57. 前記受信されるネットワークメタデータを転送するステップは、前記ネットワークメタデータの起源のインジケータを変える、請求項２に記載の方法。
58. 前記受信されるネットワークメタデータを転送するステップは、前記ネットワークメタデータの起源のインジケータを変えない、請求項２に記載の方法。
59. 変換されて転送されるネットワークメタデータを認証するステップをさらに含む、請求項３に記載の方法。
60. 前記認証するステップは、強力に暗号化した認証を実装する、請求項５９に記載の方法。
61. 前記認証するステップは、強力に暗号化していない認証を実装する、請求項５９に記載の方法。
62. ネットワークメタデータを分類する方法であって、
    不変ネットワークメタデータ定義固有の識別子を計算するステップと、
    少なくとも１つの処理規則を前記ネットワークメタデータ固有の識別子に関連づけるステップと、
    前記ネットワークメタデータ定義固有の識別子を第１の情報コンテナに格納するステップと、
    前記少なくとも１つの処理規則を前記第１の情報コンテナに格納するステップと、
    前記少なくとも１つの処理規則を、前記第１の情報コンテナ内の前記ネットワークメタデータ定義固有の識別子に関連づけるステップと、
    一意に識別されるソースから、ネットワークメタデータ定義および第１の過渡的なネットワークメタデータ識別子を含む情報の第１のパケットを受信するステップと、
    不変ネットワークメタデータ定義を前記第１のパケットに位置決めするステップと、
    前記第１のパケットにおけるネットワークメタデータ定義に対応する不変ネットワークメタデータ定義固有の識別子を計算するステップと、
    前記ネットワークメタデータ定義固有の識別子を前記第１の情報コンテナに位置決めするステップと、
    前記第１の過渡的なネットワークメタデータ識別子および前記ソース識別子を第２の情報コンテナに格納するステップと、
    前記第２の情報コンテナにおける前記第１の過渡的なネットワークメタデータ識別子を、前記第１の情報コンテナにおける前記ネットワークメタデータ定義固有の識別子に関連づけるステップと、
    ネットワークメタデータと、前記第１の過渡的なネットワークメタデータ識別子と、前記ソース識別子とを含む情報の第２のパケットを受信するステップと、
    前記第１の過渡的なネットワークメタデータ識別子および前記ソース識別子を前記第２の情報コンテナに位置決めするステップと、
    前記第２の情報コンテナにおける前記関連づけを用いて、ネットワークメタデータ定義固有の識別子を前記第１の情報コンテナ内に位置決めするステップと、
    前記第１の情報コンテナにおけるネットワークメタデータ定義固有の識別子の前記関連づけを用いて、前記処理規則を位置決めするステップと、
    前記処理規則を実行してネットワークメタデータを分類するステップとを含む方法。
63. 前記一意に識別されるソースから、ネットワークメタデータ定義および第２の過渡的なネットワークメタデータ識別子を含む情報の第３のパケットを受信することと、
    不変ネットワークメタデータ定義を前記第３のパケットに位置決めすることと、
    前記第３のパケットにおけるネットワークメタデータ定義に対応する不変ネットワークメタデータ定義固有の識別子を計算することと、
    前記ネットワークメタデータ定義固有の識別子を前記第１の情報コンテナに位置決めすることと、
    前記第２の過渡的なネットワークメタデータ識別子および前記ソース識別子を第２の情報コンテナに格納することと、
    前記第２の情報コンテナにおける前記第２の過渡的なネットワークメタデータ識別子を、前記第１の情報コンテナにおける前記ネットワークメタデータ定義固有の識別子に関連づけることと、
    前記第１の過渡的なネットワークメタデータ識別子を、前記ソース識別子を用いて前記第２の情報コンテナに位置決めすることと、
    前記第１の過渡的なネットワークメタデータ識別子および前記ソース識別子を前記第２のコンテナから除去することと、
    ネットワークメタデータと、前記第２の過渡的なネットワークメタデータ識別子と、前記ソース識別子とを含む情報の第４のパケットを受信することと、
    前記第２の過渡的なネットワークメタデータ識別子および前記ソース識別子を前記第２の情報コンテナに位置決めすることと、
    前記第２の情報コンテナにおける前記関連づけを用いて、ネットワークメタデータ定義固有の識別子を前記第１の情報コンテナ内に位置決めすることと、
    前記第１の情報コンテナにおけるネットワークメタデータ定義固有の識別子の前記関連づけを用いて、前記処理規則を位置決めすることと、
    前記処理規則を実行してネットワークメタデータを分類することとをさらに含む、請求項６２に記載の方法。
64. 前記第１の過渡的なネットワークメタデータ識別子およびソース識別子を前記第２のコンテナから除去する前記ステップは、前記第２のコンテナに格納されるエレメントにエージングアルゴリズムを適用することによって実行される、請求項６２に記載の方法。
65. 不変ネットワークメタデータ定義固有の識別子を計算する前記ステップは、不変ネットワークメタデータ定義のハッシュ値を計算することを含む、請求項６２に記載の方法。
66. 前記ハッシュ値は、暗号論的に強いアルゴリズムを用いて計算される、請求項６５に記載の方法。
67. 前記ハッシュ値は、非暗号論的に強いアルゴリズムを用いて計算される、請求項６５に記載の方法。
68. 前記処理規則は、ネットワークメタデータ処理を統率するポリシである、請求項６２に記載の方法。
69. 前記ポリシは、少なくとも部分的に、前記ネットワークメタデータのコンテンツを基礎とする、請求項６８に記載の方法。
70. 前記ポリシは時間ベースである、請求項６８に記載の方法。
71. ネットワーク上のＳＩＥＭシステムへ供給されるネットワークメタデータの量を選択的に減らす方法であって、
    少なくとも部分的に冗長メタデータを含むネットワーク・メタデータ・パケットを識別するステップと、
    少なくとも部分的に冗長メタデータを含む前記ネットワーク・メタデータ・パケットを処理して、関心のあるメタデータを保全しながら前記パケットをより少ないパケット数に集約するステップとを含む方法。
72. ネットワークメタデータを処理するためのシステムであって、
    複数のソースからネットワークメタデータを少なくとも１つのデータフォーマットで受信するように適合化されるネットワークノードと、
    前記ネットワークメタデータのタイプまたは特徴を決定するための処理モジュールと、
    有益な情報を抽出するために前記ネットワークメタデータを処理するための処理モジュールと、
    少なくとも部分的に前記決定するステップの結果に応じて、前記ネットワークメタデータの少なくとも一部を１つまたは複数の異なるデータフォーマットに変換するための処理モジュールとを備えるシステム。
73. ネットワークメタデータを分類するためのシステムであって、
    不変ネットワークメタデータ定義固有の識別子を計算するためのプロセッサと、
    少なくとも１つの処理規則を前記ネットワークメタデータ固有の識別子に関連づけるためのプロセッサと、
    前記ネットワークメタデータ定義固有の識別子を第１の情報コンテナに格納するためのプロセッサと、
    前記少なくとも１つの処理規則を前記第１の情報コンテナに格納するためのプロセッサと、
    前記少なくとも１つの処理規則を、前記第１の情報コンテナ内の前記ネットワークメタデータ定義固有の識別子に関連づけるためのプロセッサと、
    ネットワークメタデータ定義および過渡的なネットワークメタデータ識別子を含む情報の第１のパケットを受信するためのプロセッサと、
    不変ネットワークメタデータ定義を前記第１のパケットに位置決めするためのプロセッサと、
    前記第１のパケットにおけるネットワークメタデータ定義に対応する不変ネットワークメタデータ定義固有の識別子を計算するためのプロセッサと、
    前記ネットワークメタデータ定義固有の識別子を前記第１の情報コンテナに位置決めするためのプロセッサと、
    前記過渡的なネットワークメタデータ識別子を第２の情報コンテナに格納するためのプロセッサと、
    前記第２の情報コンテナにおける前記過渡的なネットワークメタデータ識別子を、前記第１の情報コンテナにおける前記ネットワークメタデータ定義固有の識別子に関連づけるためのプロセッサと、
    ネットワークメタデータと、前記過渡的なネットワークメタデータ識別子とを含む情報の第２のパケットを受信するためのプロセッサと、
    前記過渡的なネットワークメタデータ識別子を前記第２の情報コンテナに位置決めするためのプロセッサと、
    前記第２の情報コンテナにおける前記関連づけを用いて、ネットワークメタデータ定義固有の識別子を前記第１の情報コンテナ内に位置決めするためのプロセッサと、
    前記第１の情報コンテナにおけるネットワークメタデータ定義固有の識別子の前記関連づけを用いて、前記処理規則を位置決めするためのプロセッサと、
    前記処理規則を実行してネットワークメタデータを分類するためのプロセッサとを備えるシステム。
74. ネットワークシステムであって、
    ローカルネットワークを備え、前記ローカルネットワークは、
    ネットワークメタデータの第１のコレクションをｓｙｓｌｏｇフォーマットで生成する、前記ネットワーク上の複数のデバイスと、
    ｓｙｓｌｏｇデータを受信するように適合化されるネットワーク監視装置と、
    ネットワークメタデータの第２のコレクションをｓｙｓｌｏｇデータのフォーマット以外のフォーマットで生成する、前記ネットワーク上の複数のデバイスと、
    前記ネットワークメタデータの第２のコレクションの少なくとも一部をｓｙｓｌｏｇフォーマットに変換できる第１のネットワークメタデータ処理装置と、
    前記第１のネットワークメタデータ処理装置の変換された出力を前記ネットワーク監視装置へ入力として供給するための通信媒体とを備えるネットワークシステム。
75. 前記第１のネットワークメタデータ処理装置は、前記ネットワークメタデータの第２のコレクションの少なくとも一部を、前記ネットワークメタデータの第２のコレクションの前記少なくとも一部をｓｙｓｌｏｇフォーマットに変換する前に処理するためのプロセスを含む、請求項７４に記載のネットワークシステム。
76. 前記プロセッサは、前記ネットワークメタデータの第２のコレクション内に含まれるメッセージのタイプを決定できる分類子を備える、請求項７５に記載のネットワークシステム。
77. 前記プロセッサは、前記ネットワークメタデータの第２のコレクション内の各メッセージを、少なくとも部分的に前記分類子によるタイプの決定を基礎として選択的に処理できるポリシモジュールを備える、請求項７５に記載のネットワークシステム。
78. 前記ポリシモジュールは、少なくとも部分的に前記分類子によるタイプの決定を基礎として各メッセージに１つまたは複数のポリシを適用する、請求項７７に記載のネットワークシステム。
79. リモートサブネットをさらに備え、前記リモートサブネットは、
    ネットワークメタデータの第３のコレクションをｓｙｓｌｏｇフォーマットで生成する、前記リモートサブネット上の複数のデバイスと、
    ネットワークメタデータの第４のコレクションをｓｙｓｌｏｇデータのフォーマット以外のフォーマットで生成する、前記サブネット上の複数のデバイスと、
    前記ネットワークメタデータの第４のコレクションの少なくとも一部をｓｙｓｌｏｇフォーマットに変換できる第２のネットワークメタデータ処理装置と、
    前記第２のネットワークメタデータ処理装置の変換された出力を前記ネットワーク監視装置へ入力として供給するための通信媒体とを備える、請求項７４に記載のネットワークシステム。
80. ＷＡＮ上でブランチネットワークから主要ネットワークへＮｅｔＦｌｏｗメッセージを伝送する信頼性を高める方法であって、
    前記ブランチネットワーク上で生成されるＮｅｔＦｌｏｗメッセージの少なくとも一部をｓｙｓｌｏｇメッセージに変換するステップと、
    ＵＤＰより信頼性のあるネットワークプロトコルを利用して、前記変換されたｓｙｓｌｏｇメッセージを前記ブランチネットワークから前記主要ネットワーク上のサーバへ転送するステップとを含む方法。