特表 2023-540440 ローカル監視デバイスを用いた分散ネットワーク監視のためのシステム、方法及び媒体

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

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

(11)【公表番号】

(43)【公表日】2023-09-25

(54)【発明の名称】ローカル監視デバイスを用いた分散ネットワーク監視のためのシステム、方法及び媒体

(51)【国際特許分類】

   H04L 43/022 20220101AFI20230915BHJP

   G06F 21/55 20130101ALI20230915BHJP

【ＦＩ】

H04L43/022

G06F21/55 320

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023507658

(86)(22)【出願日】2021-08-06

(85)【翻訳文提出日】2023-03-29

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

(87)【国際公開番号】W WO2022032065

(87)【国際公開日】2022-02-10

(31)【優先権主張番号】63/062,216

(32)【優先日】2020-08-06

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

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

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

２．ＷＩＮＤＯＷＳ

３．ＨＡＤＯＯＰ

４．ＮＥＯ４Ｊ

５．ＣＲＡＹ

(71)【出願人】

【識別番号】500480919

【氏名又は名称】メイヨ フオンデーシヨン フオー メデイカル エジユケーシヨン アンド リサーチ

(74)【代理人】

【識別番号】100134832

【弁理士】

【氏名又は名称】瀧野 文雄

(74)【代理人】

【識別番号】100165308

【弁理士】

【氏名又は名称】津田 俊明

(74)【代理人】

【識別番号】100115048

【弁理士】

【氏名又は名称】福田 康弘

(72)【発明者】

【氏名】テチェンティン ロバート ダブリュ．

(72)【発明者】

【氏名】ホルムズ サード デイヴィッド アール．

(72)【発明者】

【氏名】ギルバート バリー ケイ．

(57)【要約】

開示された主題のいくつかの実施形態によれば、分散ネットワーク監視のためのメカニズムが提供される。いくつかの実施形態では、分散ネットワーク監視のためのシステムはローカルモニタを備え、各ローカルモニタがプロセッサを備え、プロセッサは、コンピューティングデバイスとルータとの間の正常なネットワークトラフィックのモデルを生成し、追加のトラフィックを受け取り、追加のトラフィックのメタデータのパラメータに基づいてメトリックを計算し、メトリックに基づいて追加のトラフィックが異常か否かを判断し、中央監視システムに、追加のトラフィックが異常であることを示す情報を送るようプログラムされており、中央監視システムは第２のプロセッサを備え、第２のプロセッサは、追加のトラフィックが異常であることを示す情報を受け取り、追加のトラフィックに関する情報を受け取り、この情報に基づいて、追加のトラフィックが異常であると判断し、追加のトラフィックに関連するネットワークの一部を介する通信を保護するためのアクションを起こすようにプログラムされている。
【選択図】図１

【特許請求の範囲】

【請求項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】

前記第２の期間にわたって受け取った前記ネットワークトラフィックが異常であることを確認する工程が、
前記第２の期間にわたって前記ネットワークトラフィックを受け取ったローカル監視デバイスを含むローカル監視デバイスのクラスターを識別する工程と、
前記第２の期間にわたって受け取った前記ネットワークトラフィックに関する前記情報を、前記ローカル監視デバイスの前記クラスターに関連する正常なネットワークトラフィックの第３のモデルと比較する工程であって、前記第３のモデルが、前記クラスター内の複数のローカル監視デバイスに関連する正常なネットワークトラフィックのモデルに基づいて生成されたものである、工程と、
前記正常なネットワークトラフィックの前記第３のモデルと比較して前記メトリックが異常であることに基づいて、前記第２の期間にわたって受け取った前記ネットワークトラフィックが異常であることを確認する工程と、を有する、請求項２３に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

＜関連出願の相互参照＞
本出願は、２０２０年８月６日付けで出願された米国仮出願第６３／０６２，２１６号に基づくものであり、その利益を主張するとともに、その優先権を主張する。

【0002】

＜連邦政府による支援を受けた研究に関する言及＞
該当せず。

【背景技術】

【0003】

近代的な大規模ネットワーク（企業ネットワーク、政府ネットワーク、大学ネットワークなど）の監視は、いくつかの理由から困難である。まず、ネットワークは大規模で複雑である。例えば、Ｍａｙｏ Ｃｌｉｎｉｃでは、イントラネットが７つの州の３００を超える建物にまたがり、６万人を超える従業員をサポートしている。２０２１年頃には１時間あたり数十億のフローと９０ＴＢを超えるデータを送受信し、これが毎年倍増するような２５万を超えるネットワークシステムが存在する。ユニークなエージェント振る舞い（ユーザ、システム、及び／又はソフトウェアなど）の数ははっきりと計算されていないが、おそらく数万にのぼる可能性が高い。

【0004】

さらに、そのようなネットワークのデータを分析のために中央の場所に収集することは困難である。ネットワーク防御に必要なデータの２つの異なる側面から課題が生じる。第１に、ネットワークオペレーションセンターが脅威レポートを調査して理解するために必要なデータはあまりに多様である。これらのタイプのデータには、認証ログ、ワークステーションウイルススキャンからのレポート、脅威インテリジェンスレポート、及びネットワークファイアウォールや侵入防止システム（ＩＰＳ）からのアラートが含まれる。第２に、送信元の多様性よりもさらに困難なのは膨大な量のネットワーク情報である。すべてのネットワークデータを記録することは現実的ではないが、ネットワークトラフィックの「メタデータ」を収集して分析することは一般的である。メタデータは、通常は収集された送信元と宛先、プロトコル、及びトラフィック量の時間サンプルに関して、ネットワーク上のデータ伝送を簡潔に特徴付けるために使用される。大規模ネットワークのメタデータサマリだけでも１日あたり数十億のレコードに達する可能性がある。ネットワークフォレンジックでは、侵入が数週間又は数か月間発見されないことが多いため、かなりのイベント履歴が必要である。脅威レポートを確認したり侵入者を探したりするために設計された分析ツールは、多くの場合、大規模ネットワークのサイズと複雑さに対応することができない。膨大な量のネットワークメタデータがあることから、一部のシステムはトラフィックメタデータをサンプリングする（例えば、１０％）。サンプルサイズが小さいとネットワーク容量プランニングには役立つが、脅威を検出する能力は大きく低下する。

【0005】

ネットワークに対する可視性も多くの場合、監視システム自体によって制限される。多くの商用及びオープンソース侵入検出及び防止システム、ファイアウォール、ウェブ及び電子メールフィルタ、並びにその他のネットワーク監視アプライアンスが存在し、これらは大規模企業ネットワークに展開された場合、各システムがネットワークトラフィックのいくつかの側面を監視する責任を負うような分散方式で動作する。また、ネットワークトラフィックのメタデータとコンテンツをスキャンしてマルウェアや脅威振る舞いの特定のパターンを検出できるネットワーク「プローブ」もある。ただし、各監視システムはネットワークの一部しかみない。例えば企業ネットワークとインターネットの間に配置されたウェブフィルタシステムは、ダウンロードファイル内のマルウェア、又はマルウェアの挿入、アクティブ化及び／若しくは動作のパターンを識別しようと試み得る。しかしながら、このシステムは、内部ウェブサーバとクライアント間で動いているマルウェア又はマルウェアの挿入、アクティブ化及び／若しくは操作のパターンを必ずしも取り込めるとは限らない。

【0006】

ネットワークの監視及びセキュリティイベントの管理も、セキュリティイベントについての高い誤検出率に悩まされることが多い。必然的な規模のネットワークのオペレータは、通常、セキュリティオペレーションセンター（ＳＯＣ）を実装しており、その中心にあるのはセキュリティ情報イベント管理（ＳＩＥＭ）システムである。セキュリティ分析システムは、データとアラートを一元化されたリポジトリに自動的に収集し、ＳＩＥＭは、イベントの分析、セキュリティチームが対処できるイベントのトリアージ及び優先順位付けを支援しようとする。１つの組織では、ネットワークは、独立して動作するか又は調整されたかたちで（例えば、階層に基づいて）動作する複数のＳＯＣ及びＳＩＥＭを含む場合がある。

【0007】

一般に、ネットワークセキュリティ分析性能はネットワークから取得できるデータに依存し、そのデータの可用性は利用可能なセンサに依存する。発達したセキュリティ動作は、アクティブディレクトリ認証サーバやドメインネームサービス（ＤＮＳ）サーバなどの集中型サービスからイベントデータを収集する。多くの場合、ネットワークインフラストラクチャによって提供されることが多い何らかの形式のメタデータも収集する。ネットワークオペレータは、ネットワークに「プローブ」をインストールすることもでき、プローブは高度なトラフィック分析を実行し、異常な又は脅威的な振る舞いを集中型オペレーションシステムにレポートする。しかしながらこれらのプローブは比較的高価であり、主要なネットワークロケーションにのみ展開される。ネットワークベースの侵入検出システムはＮＩＤＳと呼ばれることがあることに留意されたい。このようなシステムは、多くの場合、インターネットから入ってくる及び出ていくトラフィックに関する情報を収集するホストベースの侵入検出システム（ＨＩＤＳ）と共に展開される。多くの場合「Ｚｅｅｋ」（以前は「ＢＢｒｏｓ」と呼ばれていた）などのオープンソースプローブが高性能サーバに展開され、少なくとも数千ドルの費用がかかり、市販のプローブは、性能にもよるが、ゆうに５０，０００ドル以上の費用がかかる。

【0008】

したがって、ローカル監視デバイスを用いた分散ネットワーク監視のための新しいシステム、方法及び媒体が望まれる。

【発明の概要】

【0009】

開示された主題のいくつかの実施形態では、ローカル監視デバイスを使用した分散ネットワーク監視のためのシステム、方法及び媒体が提供される。

【0010】

開示された主題のいくつかの実施形態では、分散ネットワーク監視のためのシステムが提供され、当該システムは複数のローカル監視デバイスを備え、複数のローカル監視デバイスは、各々、少なくとも１つのコンピューティングデバイスとネットワークルータとの間に配置され、複数のローカル監視デバイスの各特定のローカル監視デバイスは、少なくとも１つのプロセッサを備え、少なくとも１つのプロセッサは、第１の期間にわたって、少なくとも１つのコンピューティングデバイスと特定のローカル監視デバイスに関連するネットワークルータとの間のネットワークトラフィックを受け取り、少なくとも１つのコンピューティングデバイスと特定のローカル監視デバイスに関連するネットワークルータとの間のネットワークトラフィックに基づいて、第１の期間にわたる正常なネットワークトラフィックのモデルを生成し、第１の期間に続く第２の期間にわたって、少なくとも１つのコンピューティングデバイスと特定のローカル監視デバイスに関連するネットワークルータとの間のネットワークトラフィックを受け取り、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータに基づいてメトリックを計算し、メトリックに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常か否かを判断し、第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、中央監視システムに、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を送るようにプログラムされており、中央監視システムは、少なくとも１つの第２のプロセッサを備え、少なくとも１つの第２のプロセッサは、複数のローカル監視デバイスの第１のローカル監視デバイスから、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を受け取り、第１のローカル監視デバイスから、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックに関する情報を受け取り、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックに関する情報に基づいて、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断し、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、第１のローカル監視デバイスに関連するネットワークの一部を介する通信を保護するためのアクションを起こすようにプログラムされている。

【0011】

いくつかの実施形態では、少なくとも１つのプロセッサは、正常なネットワークトラフィックのモデルに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であるか否かを判断するようにさらにプログラムされている。

【0012】

いくつかの実施形態では、ネットワークトラフィックに関する情報は、第１のローカル監視デバイスによって生成される正常なネットワークトラフィックのモデルを備える。

【0013】

いくつかの実施形態では、メトリックは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータのエントロピーを含む。

【0014】

いくつかの実施形態では、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータは、送信元ＩＰアドレスを含む。

【0015】

いくつかの実施形態では、第１の期間にわたる正常なネットワークトラフィックのモデルは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータの平均エントロピー値に基づく範囲を備える。

【0016】

いくつかの実施形態では、第１のローカル監視デバイスに関連するネットワークの一部を介する通信を保護するためのアクションは、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックが異常であったことを示すアラートをユーザに提示することを含む。

【0017】

いくつかの実施形態では、第１のローカル監視デバイスに関連するネットワークの一部を介する通信を保護するためのアクションは、第１のローカル監視デバイスに、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックを異常にした原因となる送信元ＩＰアドレスからのトラフィックをブロックさせることを含む。

【0018】

いくつかの実施形態では、少なくとも１つのプロセッサは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を備え、少なくとも１つのプロセッサは、少なくとも部分的にＦＰＧＡの論理ゲートの構成に基づいてプログラムされている。

【0019】

いくつかの実施形態では、少なくとも１つのプロセッサは、特定用途向け集積回路（ＡＳＩＣ）を備え、少なくとも１つのプロセッサは、少なくとも部分的にＡＳＩＣの論理ゲートの構成に基づいてプログラムされている。

【0020】

開示された主題のいくつかの実施形態では、分散ネットワーク監視のための装置が提供され、当該装置は少なくとも１つのプロセッサを備え、少なくとも１つのプロセッサは、第１の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取り、第１の期間にわたる正常なネットワークトラフィックのモデルを生成し、第１の期間に続く第２の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取り、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータに基づいてメトリックを計算し、メトリックに基づいて、正常なネットワークトラフィックのモデルを使用して、第２の期間にわたって受け取ったネットワークトラフィックが異常か否かを判断し、第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、中央監視システムに、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を送るようにプログラムされている。

【0021】

いくつかの実施形態では、装置の少なくとも１つのプロセッサは、第１の期間にわたる正常なネットワークトラフィックのモデルを中央監視システムに送るようにさらにプログラムされている。

【0022】

いくつかの実施形態では、装置は第１のイーサネットポートと第２のイーサネットポートとをさらに備え、少なくとも１つのプロセッサは、第１のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも一部を受け取るようにさらにプログラムされている。

【0023】

いくつかの実施形態では、装置の少なくとも１つのプロセッサは、第２のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも一部を、少なくとも１つのコンピューティングデバイスに送るようにさらにプログラムされている。

【0024】

いくつかの実施形態では、装置の少なくとも１つのプロセッサは、第２のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも第２の部分を受け取り、第１のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも第２の部分をネットワークルータに送るように、さらにプログラムされている。

【0025】

いくつかの実施形態では、メトリックは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータのエントロピーを含む。

【0026】

いくつかの実施形態では、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータは、宛先ポートを含む。

【0027】

いくつかの実施形態では、第１の期間にわたる正常なネットワークトラフィックのモデルは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータの平均エントロピー値に基づく範囲を備える。

【0028】

いくつかの実施形態では、装置の少なくとも１つのプロセッサは、中央監視システムから、装置が第２の期間にわたって受け取ったネットワークトラフィックを異常にした原因となる送信元ＩＰアドレスからのトラフィックをブロックする命令を受け取るように、さらにプログラムされている。

【0029】

いくつかの実施形態では、装置の少なくとも１つのプロセッサは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を備え、少なくとも１つのプロセッサは、少なくとも部分的にＦＰＧＡの論理ゲートの構成に基づいてプログラムされている。

【0030】

開示された主題のいくつかの実施形態では、分散ネットワーク監視のための方法が提供され、当該方法は、第１の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取る工程と、第１の期間にわたる正常なネットワークトラフィックのモデルを生成する工程と、第１の期間に続く第２の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取る工程と、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータに基づいて、メトリックを計算する工程と、メトリックに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常か否かを判断する工程と、第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、中央監視システムに、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を送る工程と、を有する。

【0031】

いくつかの実施形態では、第１の期間にわたる正常なネットワークトラフィックのモデルを中央監視システムに送る工程をさらに有する。

【0032】

いくつかの実施形態では、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を受け取る工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報を受け取る工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報に基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程と、第２の期間にわたって受け取ったネットワークトラフィックが異常であることが確認されたことに応えて、第２の期間にわたって受け取ったネットワークトラフィックに関連するネットワークの一部を介する通信を保護するためのアクションを起こす工程と、を有する。

【0033】

いくつかの実施形態では、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程が、第２の期間にわたってネットワークトラフィックを受け取ったローカル監視デバイスを含むローカル監視デバイスのクラスターを識別する工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報を、クラスター内の別のローカル監視デバイスに関連する正常なネットワークトラフィックの第２のモデルと比較する工程と、正常なネットワークトラフィックの第２のモデルと比較してメトリックが異常であることに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程と、を有する。いくつかの実施形態では、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程が、第２の期間にわたってネットワークトラフィックを受け取ったローカル監視デバイスを含むローカル監視デバイスのクラスターを識別する工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報を、クラスター内の別のローカル監視デバイスに関連する正常なネットワークトラフィックの第３のモデルと比較する工程であって、前記第３のモデルが、前記クラスター内の複数のローカル監視デバイスに関連する正常なネットワークトラフィックのモデルに基づいて生成されたものである、工程と、正常なネットワークトラフィックの第３のモデルと比較してメトリックが異常であることに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程と、を有する。

【0034】

開示された主題の様々な目的、特徴及び利点は、開示された主題の以下の詳細な説明を参照して、同様の参照符号が同様の要素を示す以下の図面と関連して考慮することにより、より完全に理解することができる。

【図面の簡単な説明】

【0035】

【図1】開示された主題のいくつかの実施形態による、ローカル監視デバイスを使用した分散ネットワーク監視のためのシステムの例を示す図である。

【図2】開示された主題のいくつかの実施形態による、図１のローカル監視デバイス、中央監視システム、及びコンピューティングデバイスを実装するために使用できるハードウェアの例を示す。

【図3】開示された主題のいくつかの実施形態による、ローカル監視デバイスを使用する分散ネットワーク監視のためのシステムのより具体的な例を示す。

【図4】開示される主題のいくつかの実施形態による、ローカル監視デバイスを使用してネットワークの一部を監視するためのプロセスの例を示す。

【図5】開示された主題のいくつかの実施形態による、ローカル監視デバイスから受け取ったネットワークデータに基づいて悪意のある可能性があるアクティビティを検出するためのプロセスの例を示す。

【図6】開示された主題のいくつかの実施形態による、ローカル監視デバイスから受け取ったネットワークトラフィックのモデルに基づいて悪意のある可能性があるアクティビティを検出するためのプロセスの例を示す。

【図7】開示された主題のいくつかの実施形態による、ローカル監視デバイスによる異常検出に使用できる経時的なエントロピーの例を示す。

【図8A-C】図８Ａは、組織イントラネット内の様々なシステムのそれぞれにおけるサブネットの数のプロットを線形軸で示す。図８Ｂは、組織イントラネット内の様々なシステムのそれぞれにおけるサブネットの数のプロットを対数目盛のついたｙ軸で示す。図８Ｃは、組織イントラネット内の様々なシステムのそれぞれにおけるサブネットの数のプロットを両対数軸（ｘ軸及びｙ軸）で示す。

【図9】組織イントラネット内の様々なシステムのサブネットの数に対する送信元アドレス数と宛先アドレス数の散布図を両対数軸で示す。

【図10】組織イントラネット内のウェブサーバについての送信元及び宛先アドレスの組み合わせの散布図を両対数軸で示す。

【図11】組織イントラネット内のシステムのグループについての送信元及び宛先アドレスの組み合わせの散布図を両対数軸で示す。

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

【0036】

種々の実施形態によれば、ローカル監視デバイスを使用した分散ネットワーク監視のためのメカニズム（例えば、システム、方法及び媒体を含むことができる）が提供される。

【0037】

開示された主題のいくつかの実施形態によれば、本明細書において記載されるメカニズムを使用して、大規模で複雑なコンピュータネットワークを監視するためのマルチレベルアプローチを実装するために使用できるローカル監視デバイスを実装することができる。いくつかの実施形態では、そのようなローカル監視デバイスは、小さく、低電力で、安価であり、組織のイントラネット内に広く展開され得る。例えば、各ローカル監視デバイスを配置して、ネットワーク全体の比較的小さな部分の監視又はオーバーウォッチを提供するための可視性をもたらす及びそのための責任を負うことができる。このような例では、各ローカル監視デバイスは、ネットワークトラフィックの略リアルタイム分析を実行することができる。要約すると、本明細書に記載されるメカニズムは、ネットワーク監視及び／又は保護のための分散型超並列処理システムとして機能できるリモート監視デバイスの展開を容易にすることができる。

【0038】

いくつかの実施形態では、本明細書に記載されるメカニズムを使用して、異常な振る舞いを識別する、及び／又は脅威を検出するローカル監視デバイスを実装することができる。例えば、いくつかの実施形態では、ローカル監視デバイスは、トラフィックのローカルビューから「正常な」ネットワークの振る舞いを学習し、情報エントロピーを使用して異常を検出することができる。いくつかの実施形態では、異常な振る舞い及び／又は検出された脅威は、ネットワーク全体のより大きなコンテキストでレポートを評価するように構成できる中央監視システムに送ることができる。いくつかの実施形態では、本明細書に記載されるメカニズムによって容易となる機能と時間スケールの二層分離により、全体的なコストが劇的に削減され、現代のネットワークセキュリティ運用センターを悩ませている誤検出アラートが大幅に減少し、及び／又は、提供される脅威発見と保護を集約システムによって拡張することができる。

【0039】

いくつかの実施形態では、本明細書に記載されるメカニズムを使用して、ネットワーク内に広く展開することができ、（例えば、ネットワークセキュリティ「プローブ」と比較して）比較的低いユニットあたりのコストで実装できるローカル監視デバイスを実装することができる。

【0040】

図１は、開示される主題のいくつかの実施形態による、ローカル監視デバイスを使用する分散ネットワーク監視のためのシステムの例１００を示す。図１に示すように、システム１００は、１つ又は複数のコンピューティングデバイス１０４などにネットワークの一部上で通信されるトラフィックを監視するために使用できる様々なローカル監視デバイス１０２を含むことができる。いくつかの実施形態では、ローカル監視デバイス１０２は、ネットワーク内の様々なポイントで接続され得る。例えば、ローカル監視デバイス１０２は、エンドポイント（例えば、単一のコンピューティングデバイス１０４）と通信ネットワーク１０６との間に接続されてもよい。例えば、いくつかの実施形態では、特定のコンピューティングデバイス１０４は、通信リンク１１０、特定のローカル監視デバイス１０２及び通信リンク１１２を介して通信ネットワーク１０６に接続することができる。例えば、通信リンク１１０及び１１２は、イーサネット（登録商標）リンク、ＵＳＢリンク、Ｗｉ－Ｆｉ直接リンク、ブルートゥース（登録商標）などの有線若しくは無線ネットワークリンク、又は他のタイプのローカルポイントツーポイント接続、又はそれらの適切な組み合わせであり得る。いくつかの実施形態では、通信リンク１１０及び通信リンク１１２は、同じ通信プロトコルを使用することができる。あるいは、いくつかの実施形態では、通信リンク１１０は１つのプロトコルを使用することができ、通信リンク１１２は異なる通信プロトコルを使用することができる。

【0041】

いくつかの実施形態では、特定のコンピューティングデバイス１０４は、１つ又は複数のネットワークインフラストラクチャデバイス１２２、１つ又は複数の通信リンク１２４、特定のローカル監視デバイス１０２、及び通信リンク１１２を介して、通信ネットワーク１０６に接続することができる。いくつかの実施形態では、ネットワークインフラストラクチャデバイス１２２は、１つ又は複数の無線アクセスポイント（例えば、Ｗｉ－Ｆｉアクセスポイント）、１つ又は複数のネットワークスイッチ、１つ又は複数のネットワークルータ、及び任意の他の適切なネットワークインフラストラクチャデバイス、又はこれらの任意の適切な組み合わせであり得る。例えば、ネットワークインフラストラクチャデバイス１２２は、１つ又は複数のコンピューティングデバイス１０４とスイッチ又はルータとの間に接続された無線アクセスポイントであり得る。そのような例では、ローカル監視デバイス１０２は、アクセスポイントとルータ又はスイッチとの間に接続されてもよい。別の例として、ネットワークインフラストラクチャデバイス１２２は、複数のコンピューティングデバイス１０４及び／又は他のネットワークインフラストラクチャデバイスと、別のルータ（例えば、ローカルルータ又はネットワークアクセスゲートウェイとして機能する）、スイッチなどとの間に接続されてもよい。いくつかの実施形態では、コンピューティングデバイス１０４は、パーソナルコンピュータ、ラップトップコンピュータ、医療機器、タブレットコンピュータ、スマートフォン、ウェアラブルコンピュータなどの任意の適切なコンピューティングデバイスであってもよい。いくつかの実施形態では、コンピューティングデバイス１０４は、物理コンピューティングデバイスによってホストされる仮想化デバイスであってもよい。例えば、単一の物理コンピューティングデバイスは、仮想化テクノロジーを使用するデータセンターのユーザに対して、独立したコンピューティングデバイスとして表示及び動作する仮想マシンの１つ又は複数の例をホストできる。単一の物理コンピューティングデバイスは、動的な方法で仮想マシンを作成、維持、削除、又はその他のかたちで管理できる。いくつかの実施形態では、様々な物理及び／又は仮想コンピューティングデバイス１０４を、オペレーティングシステム若しくはオペレーティングシステム構成、仮想化ハードウェアリソース、及びソフトウェアアプリケーションの様々な組み合わせに関連付けて、コンピューティングデバイスが異なる機能を提供できるようにする、及び／又は、同様の機能をより効率的に提供できるようにすることができる。さらに、仮想マシンは、「コンテナ」と呼ばれることもある複数の分離された仮想システムに分割できる。仮想マシンは、処理パワーやメモリなどのリソースの割り当てを制御でき、各コンテナには、ソフトウェアプログラムの実行などのためにコンテナが使用できる独自のリソースを割り当てることができる。いくつかの実施形態では、ローカル監視デバイス１０２は、１つ又は複数の仮想マシンを実行している又は実行していない可能性がある、１つ又は複数の物理コンピューティングデバイスへの及び／又は当該１つ又は複数の物理コンピューティングデバイスからの通信を監視することができる。そのような実施形態では、ローカル監視デバイス１０２は、特定のアドレス（例えば、特定の物理コンピューティングデバイスに関連するＩＰアドレス、特定の仮想マシンに関連するＩＰアドレス、仮想マシンで実行中の複数のコンテナに関連するＩＰアドレスなど）への及び／又は当該特定のアドレスからの通信を独立して監視することができる。

【0042】

いくつかの実施形態では、ローカル監視デバイス１０２は、通信リンク１１２（例えば、コンピューティングデバイス１０４によって使用されるのと同じ通信リンク）、又は、コンピューティングデバイス１０２及び／若しくは通信リンク１１４によって使用されるものとは異なる通信プロトコルを使用することができる通信リンク１１４を介して、通信ネットワーク１０６に接続することができる。

【0043】

いくつかの実施形態では、通信ネットワーク１０６は、任意の適切な通信ネットワーク又は通信ネットワークの組み合わせであり得る。例えば、通信ネットワーク１０６は、インターネット、イントラネット、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線ネットワーク、デジタル加入者線（ＤＳＬ）ネットワーク、フレームリレーネットワーク、非同期転送モード（ＡＴＭ）ネットワーク、仮想プライベートネットワーク（ＶＰＮ）、他の適切な通信ネットワーク、又はそれらの適切な組み合わせとすることができる。いくつかの実施形態では、通信ネットワーク１０６は、企業又は大学のイントラネットなどのプライベート又はセミプライベートネットワークを含むことができる。いくつかの実施形態では、通信ネットワーク１０６は、Ｗｉ－Ｆｉネットワーク（１つ又は複数の無線ルータ、１つ又は複数のスイッチなどを含むことができる）、ピアツーピアネットワーク（例えば、ブルートゥース（登録商標）ネットワーク、Ｚｉｇｂｅｅ（登録商標）メッシュネットワークなど）、セルラネットワーク（例えば、ＣＤＭＡ、ＧＳＭ、ＬＴＥ、ＬＴＥ Ａｄｖａｎｃｅｄ、ＷｉＭＡＸなどの任意の適切な規格に準拠する３Ｇネットワーク、４Ｇネットワークなど）、及び有線ネットワークなどのうちの１つ又は複数を含むことができる。

【0044】

いくつかの実施形態では、システム１００は、１つ又は複数の中央監視デバイス１３０を含むことができる。いくつかの実施形態では、中央監視システム１３０は、通信リンク１３２を介して通信ネットワーク１０６に接続することができる。例えば、通信リンク１３２は、イーサネット（登録商標）リンク若しくは複数のイーサネット（登録商標）リンク、又はその他のタイプの適切な通信リンクなどの有線又は無線ネットワークリンクであってもよい。いくつかの実施形態では、中央監視システム１３０は、サーバ又は複数のサーバ、仮想マシン又は複数の仮想マシン、「スーパーコンピュータ」などの任意の適切な物理及び／又は仮想コンピューティングデバイスを使用して実装することができる。

【0045】

いくつかの実施形態では、各ローカル監視デバイス１０２は、特定のネットワーク（例えば、企業イントラネット、政府イントラネットの一部など）上のネットワークトラフィック全体の比較的小さな部分を分析することができる。例えば、各ローカル監視デバイス１０２は、単一のコンピューティングデバイス（例えば、単一のサーバ、単一の医療機器、単一のユーザコンピューティングデバイス）など、比較的少数のエンドポイントを含むネットワークの一部に接続することができる。別の例として、特定のローカル監視デバイス１０２は、複数のコンピューティングデバイス（例えば、複数のサーバ、複数の医療機器、及び／又は複数のユーザコンピューティングデバイス）に接続することができる。

【0046】

いくつかの実施形態では、各ローカル監視デバイス１０２は、ネットワークのその部分でどのような振る舞いが正常であるかを学習し、ネットワークのその部分での異常な振る舞いを検出するための１つ又は複数のトラフィックモデルを構築することができる。いくつかの実施形態では、ローカル監視デバイス１０２と中央監視システム１３０との間でトラフィックモデルを交換することができる。いくつかの実施形態では、ローカル監視デバイスと１つ又は複数の中央監視システム１３０とを利用するデュアルレベルアプローチは、ネットワーク上に広く展開されると、ネットワークに対する可視性を高めることができ、ネットワーク分析作業負荷の一部をネットワークの周辺と中央監視システム１３０との間で分散させることができる。

【0047】

いくつかの実施形態では、ローカル監視デバイスは、デバイスにインストールされたソフトウェアを介して保護することが困難なネットワーク化された医療機器（例えば、輸液ポンプ、ＣＴスキャナ、ＭＲＩスキャナなど）と接続して使用することができる。例えば、ＦＤＡ承認プロセスの難しさと費用のために、このようなネットワーク化された医療機器はほとんどパッチ適用や更新が行われず、脆弱なままになっている。ローカル監視デバイス１０２を大量生産し、それらを広く展開する能力は、ネットワークセキュリティインフラストラクチャの費用対効果の高い展開を容易にすることができる。

【0048】

いくつかの実施形態では、ローカル監視デバイス１０２は、低電力技術を使用して「Ｂｕｍｐ ｉｎ ｔｈｅ ｗｉｒｅ」デバイスとして構成することができ、これにより、費用対効果の高い方法で広範な展開を容易にすることができる。例えば、ローカル監視デバイス１０２は、コンピューティングデバイス１０４のネットワークインターフェースとネットワークの上流部分との間に接続できるドングルとして構成することができる。別の例として、ローカル監視デバイス１０２は、ネットワークインフラストラクチャデバイス１２２とネットワークの上流部分との間に接続できるドングルとして構成することができる。

【0049】

以下に説明するように、ローカル監視デバイス１０２は、中央監視システム１３０と共に、そしていくつかの実施形態では中央監視システム１３０の命令の下で、動作する。いくつかの実施形態では、中央監視システム１３０は、ローカル監視デバイス１０２と通信し、アラートを収集し、及び／又はモデルパラメータを配布することができる。いくつかの実施形態では、ローカル監視デバイス１０２は各々、トラフィックを評価し、潜在的脅威をレポートするように構成することができ、中央監視システム１３０はネットワーク全体の状況でローカル監視デバイス１０２から受け取ったレポートを評価することができる。いくつかの実施形態では、中央監視システム１３０は、特定のローカル監視デバイス１０２によって悪意のある（例えば異常である）可能性があると識別されたものの、ネットワーク内の他の場所において比較的高い信頼度で悪意のないものと識別できることが十分な規則性をもって見られた非脅威的な振る舞いを識別することができ、これにより、誤検出アラートの発生率を減らすことができる。いくつかの実施形態では、中央監視システム１３０は既知の無害なトラフィックパターンのリポジトリとしても機能することができ、それらのモデルをネットワークの適切な部分においてローカル監視デバイス１０２と共有することができる。

【0050】

いくつかの実施形態では、ローカル監視デバイス１０２は、（例えば、マルウェアスキャンソフトウェアを使用して）自己監視するための計算資源を典型的に欠いているプリンタ及びモノのインターネット（ＩｏＴ）デバイスなどのデバイスを含む任意のネットワークデバイスの近くに配置することができる。さらに、上に記載したように、ローカル監視デバイス１０２は、既知の脆弱性を排除するために（例えば、規制又は認証の問題のために）パッチの適用ができないネットワーク化された医療機器及び他のシステムの近くに配置することができる。さらに、ローカル監視デバイス１０２は、下流のネットワークデバイスがマルウェア又は他の故障によって機能障害に陥った場合でも動作し続けることができるが、一方で、ネットワークデバイスを保護するために使用されるマルウェアスキャンソフトウェアはマルウェア又は故障によって機能障害に陥りそのようなネットワークデバイスが保護されないままになる可能性がある。いくつかの実施形態では、ローカルネットワークの振る舞いについて学習し、新しいトラフィックを学習済モデルパラメータと比較し、異常を検出してレポートするというローカル監視デバイス１０２の能力は、費用対効果の高いネットワークセキュリティを容易にすることができる。例えば、各ローカル監視デバイス１０２はネットワークのごく一部しか視ることができないので、ネットワーク全体の正常な振る舞いをモデル化しようとする集中型システムよりも特徴付けられる正常な振る舞いが少ない。これによって、ローカル監視デバイス１０２が、監視されているネットワークの一部にとって普通でないトラフィックパターンを検出できる比較的シンプルなパラメータ化されたモデルを生成することを容易にすることができる。

【0051】

いくつかの実施形態では、ローカル監視デバイス１０２は、ネットワーク形成及び分析タスクを実行するためにＣＰＵを使用して実装することができる。これにより、任意の適切なソフトウェアを実行するＣＰＵの能力に基づいて比較的柔軟性のあるデバイスを実現できるが、パフォーマンスが犠牲になる可能性がある。例えば、このようなデバイスは１００Ｍｂｐｓイーサネットインターフェイスを使用する通信をサポートできるが、暗号化に関連する計算コストにより、パフォーマンスが低スループット（例えば、１０Ｍｂｐｓ未満）に制限される可能性がある。

【0052】

いくつかの実施形態では、ローカル監視デバイス１０２は、ネットワーク形成及び分析タスクを実行するためにフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を使用して実装することができる。これにより、柔軟性は低い（例えば、ＦＰＧＡは再プログラムできるが、ＣＰＵに比べて比較的柔軟性に欠ける）がパフォーマンスは高いデバイスを実現できる。例えば、ＦＰＧＡベースのデバイスは、（例えば、ロジックに暗号化及び解析機能を実装することにより）１Ｇｂｐｓイーサネットインターフェイスを経済的にサポートできる。

【0053】

いくつかの実施形態では、ローカル監視デバイス１０２は、ネットワーク形成及び分析タスクを実行するために特定用途向け集積回路（ＡＳＩＣ）を使用して実装することができる。ＡＳＩＣベースのデバイスは、柔軟性の犠牲及び開発時間の増加が伴うが、あらゆるネットワークインターフェース及びあらゆるレベルのパフォーマンスをサポートするように構成できる。例えば、ＡＳＩＣ実装の利点は、ＡＳＩＣが実行するように構成されている特定のタスクのパフォーマンスが高く、長期的にはユニット当たりのコストが低いことである。

【0054】

いくつかの実施形態では、ローカル監視デバイス１０２は、（例えば、図４の４０６に関連して以下で説明するように）トラフィックのエントロピーに基づいてネットワークトラフィックのモデルを生成することができる。例えば、エントロピーは複数の異なるメタデータパラメータについて計算でき、エントロピーの個々の測定値は、複数の異なるメタデータパラメータのエントロピーの計算に基づく比較的シンプルな異常検出アプローチとして個別に使用できる。別の例として、条件付きエントロピー及び／又はＴｓａｌｌｉｓエントロピー（例えば、参照により全体が本明細書に盛り込まれるものとするＴｅｌｌｅｎｂａｃｋらによる「Ａｃｃｕｒａｔｅ Ｎｅｔｗｏｒｋ Ａｎｏｍａｌｙ Ｃｌａｓｓｉｆｉｃａｔｉｏｎ ｗｉｔｈ Ｇｅｎｅｒａｌｉｚｅｄ Ｅｎｔｒｏｐｙ Ｍｅｔｒｉｃｓ」，Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋｓ，ｖｏｌ．５５，ｎｏ．１５，ｐｐ．３４８５－３５０２（２０１１）ＤＯＩ：１０．１０１６／ｊ．ｃｏｍｎｅｔ．２０１１．０７．００８において記載されているようなもの）などのより高度なメトリックを使用することができる。そのような例では、条件付き及び／又はＴｓａｌｌｉｓエントロピーを使用することにより、ローカル監視デバイス１０２が、詳細及び／又は外れ値を様々なスケールで効果的に認識できるようにすることができる。いくつかの実施形態では、エントロピー計算を実行するために使用できる演算子は、ルックアップテーブルとして実行できる加算、乗算及び対数関数を含むことができる。加えて又は代替的に、いくつかの実施形態では、ローカル監視デバイス１０２は、任意の他の適切なネットワーク分析に基づいてモデルを生成することができる。例えば、ローカル監視デバイス１０２は、（例えば、１つ又は複数のディープパケット検査法を使用して）シグネチャーテストを実行することができる。別の例として、ローカル監視デバイス１０２は、アドレス（例えば、送信元アドレス、宛先アドレス）を、明示的に許可された及び／又は明示的に許可されていないアドレスのリスト（それぞれホワイトリスト及びブラックリストと呼ばれることがある）と比較することができる。さらに別の例として、ローカル監視デバイス１０２は、ネットワークトラフィックにおける経時的パターンに基づいてモデルを生成することができる。さらに別の例として、ローカル監視デバイス１０２は、異常である可能性があるスキャンパターンを検出するために使用できるスキャンアクティビティに基づいてモデルを生成することができる。

【0055】

いくつかの実施形態では、ローカル監視デバイス１０２は、１つ又は複数の確率関数を使用して、ある時点のエントロピー値をヒストリカル標準（ｈｉｓｔｏｒｉｃａｌ ｎｏｒｍａｌ）と比較することができる。そのような実施形態では、確率関数は、数十又は数百のカウンタービンに除算演算子を加えたものを有し得る離散的なヒストグラムとして実行することができる。したがって、いくつかの実施形態では、高いクロック速度で確率とエントロピーの両方を計算する必要がなく、これにより、新しいデータをヒストリカル「標準（ｎｏｒｍａｌ）」と比較する確率関数を使用するため及びエントロピー計算のために実行される回路の論理性能要件を緩和することができる。

【0056】

いくつかの実施形態では、ローカルコンピューティングデバイスによって必要とされるメモリの量は、計算されたエントロピー値の数及び／又は確率ヒストグラムの解像度に応じてばらつく可能性がある。

【0057】

いくつかの実施形態では、ローカル監視デバイス１０２及び中央監視システム１３０はマルチレベルネットワーク監視システムを形成することができ、これは、（例えば、コンピューティングデバイス１０２と通信ネットワーク１０６との間のネットワーク通信に加えて）複数の通信プロトコルの慎重な実装を必要とし得る。例えば、１つ又は複数の通信プロトコルを使用することができるローカル監視デバイス１０２と中央監視システム１３０との間の通信があり得る。別の例として、中央監視システム１３０と、セキュリティ情報及びイベント管理（ＳＩＥＭ）システムなどの他のネットワーク防御システムとの間の通信があり得る。

【0058】

いくつかの実施形態では、中央監視システム１３０はローカル監視デバイス１０２と通信でき、これには、特定のローカル監視デバイス１０２にコマンドを送ること、特定のローカル監視デバイス１０２から異常な振る舞いについてのレポートを受け取ること、及び特定のローカル監視デバイス１０２に予想される振る舞いのパターン（例えば、モデル）を送ることが含まれ得る。いくつかの実施形態では、この通信は、監視されているネットワークとは別のコマンドアンドコントロールネットワーク上で実行することができ、その場合、当該実行は任意のロバストな通信プロトコルを使用することができる。例えば、通信リンク１１２が、コマンドアンドコントロールネットワークリンクであり得る。加えて又は代替的に、いくつかの実施形態では、中央監視システム１３０は、監視対象ネットワークにわたり「インバンド（ｉｎ ｂａｎｄ）」通信チャネルを使用してローカル監視デバイス１０２と通信することができる。そのような実施形態では、中央監視システム１３０及びローカル監視デバイス１０２は、監視対象ネットワークによってサポートされるプロトコルを採用して、それを使用して互いに通信しなければならない。例えば、中央監視システム１３０及びローカル監視デバイス１０２は、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、並びに／又は、任意の適切なより軽量の代替手段、例えば、ユーザデータグラムプロトコル（ＵＤＰ）及びＩｏＴアプリケーション用に開発された各種プロトコル、例えば、ＭＱテレメトリトランスポート（ＭＱＴＴ）プロトコルなどを使用することができる。

【0059】

いくつかの実施形態では、ローカル監視デバイス１０２の実装は、通信プロトコルにも影響を与える可能性がある。例えば、ローカル監視デバイス１０２は、単一のコンピューティングデバイス（例えば、ネットワーク化された医療スキャナ）を保護するように構成することができる。そのような例では、中央監視システム１３０は、特定のローカル監視デバイス１０２向けの通信（例えば、コマンド及び／又は制御パケット）を、保護されているコンピューティングデバイスに関連するアドレスにアドレス指定することができる。そのような実装では、ローカル監視デバイス１０２は、ネットワークデバイスに宛てられたトラフィックから、そのローカル監視デバイス１０２に向けの通信を傍受することができる。加えて又は代替的に、いくつかの実施形態では、特定のローカル監視デバイス１０２への通信を容易にするために、ローカル監視デバイス１０２に（例えば、コマンドアンドコントロールネットワーク上及び／又は監視対象ネットワーク上で）ネットワークアドレスを割り当てることができる。

【0060】

いくつかの実施形態では、中央監視システム１３０は、ＳＩＥＭ、１つ又は複数のネットワーク資産及び構成マネージャ、並びに他のシステムなどの他のネットワーク防御システムと通信するように構成することができる。例えば、中央監視システム１３０は、リアルタイムネットワーク振る舞いモデルに関連する情報をそのようなネットワーク防御システムに通信するように構成することができる。

【0061】

機能障害に陥ったネットワーク監視システムはネットワークへのエントリポイントとなり得ることから及び／又はネットワークの他の部分のセキュリティに問題を生じさせ得ることから、中央監視システム１３０及び／又はローカル監視デバイス１０２によって利用されるすべての通信プロトコルを保護することができる。例えば、いくつかの実施形態では、中央監視システム１３０とローカル監視デバイス１０２との間の通信は、暗号化及び／又は別の方法で保護することができる（例えば、デジタル署名によって認証されるなど）。別の例として、（複数の）認証システム及び／又はデジタルアイデンティティ管理の専用リポジトリを使用して、コマンドアンドコントロールネットワーク及び／又は監視されているネットワーク上の通信を保護できる。

【0062】

いくつかの実施形態では、監視されているネットワークの周辺近くにローカル監視デバイス１０２を展開することにより、（例えば、ネットワークのコアにより近い監視を介して実装されるシステムと比較して）中央監視システム１３０で必要とされる計算資源を削減することができる。例えば、大規模な企業ネットワーク上でのネットワークメタデータの最先端の振る舞い分析は、データのサイズと複雑さのために一般的に非常に困難である。このような集中型の監視には、通常、かなりの収集及び分析作業が必要であり、多くの場合、「スーパーコンピュータ」又は専用のプライベートクラウドリソースが必要になる。いくつかの実施形態では、監視されているネットワークの周辺近くにローカル監視デバイス１０２を展開することにより、中央分析サーバから多くのタスクをオフロードすることができるとともに、データ収集及び分析作業の作業負荷を軽減できるコンパクトな振る舞いモデルで広範な生データ収集を置き換えることができる。

【0063】

いくつかの実施形態では、中央監視システム１３０は複数の機能を実装することができる。例えば、中央監視システム１３０は、既知のネットワーク振る舞いを特徴付けるモデルのリポジトリとして機能することができる。そのような例では、特定のローカル監視デバイス１０２は、その特定のローカル監視デバイス１０２によって監視されているネットワークの一部で発見された異常な振る舞い（又は悪意のある可能性があるアクティビティ）を中央監視システム１３０にレポートすることができる。いくつかの実施形態では、中央監視システム１３０は、特定のローカル監視デバイス１０２によって特定されたアクティビティがネットワーク全体で比較的普通であるか否かを（例えば、他のローカル監視デバイスからのトラフィックモデルに基づいて）判断することができる。アクティビティが比較的普通である場合、中央監視システム１３０は誤検出が生じることを回避することができ、中央監視システム１３０は真に異常なアクティビティをより正確に識別することができる。別の例として、中央監視システム１３０は、追加の分析層及び／又はより高度な分析を提供することができる。そのような例では、中央監視システム１３０は、個々のローカル監視デバイスよりも多くの計算資源にアクセスすることができる。これにより、より高度な手法を使用した分析が容易になる。さらに、これにより、監視されているネットワークの異なる部分からの追加データを使用した分析が容易になり、何故なら、ネットワークにわたるローカル監視デバイス１０２からのレポートがネットワークのより大きな部分（例えば、ネットワーク全体）に対する可視性を提供できるからである。さらに別の例として、中央監視システム１３０は、１つ又は複数のローカル監視デバイス１０２に所定のネットワークアクティビティ（例えば、（複数の）特定のコンピューティングデバイスへの及び／又は（複数の）特定のコンピューティングデバイスからの通信、１つ又は複数のポートを使用した通信など）をブロックするように命令することによって、ネットワーク上のローカル監視デバイス１０２のためのコマンドアンドコントロールポイントとして機能することができる。

【0064】

いくつかの実施形態では、中央監視システム１３０は、トラフィックモデルのリポジトリ（例えば、カタログとして実装される）及び／又はアクティブなローカル監視デバイス１０２のデータベースとして機能する（及び／又はこれにアクセスする）ことができる。

【0065】

例えば、中央監視システム１３０は、ローカル監視デバイス１０２のデータベースを含む（及び／又はこれにアクセスする）ことができる。そのような例では、監視デバイスデータベースは、デバイス識別情報、デバイス機能情報、デバイスネットワーク位置情報、デバイス物理的位置情報、暗号化情報（例えば、特定のローカル監視デバイスによって使用される公開鍵及び／又は秘密鍵に関する情報、デバイスによって使用される暗号化スキームに関する情報）、及び／又はローカル監視デバイス１０２のサポートに使用できるその他の適切な情報を含むことができる。いくつかの実施形態では、デバイスデータベースは、任意の適切な技法又は技法の組み合わせを使用してフォーマット及び／又は実装することができる。例えば、データベースは、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）又は階層データ形式バージョン５（ＨＤＦ５）を使用してフォーマットされたファイルで実装できる。別の例として、データベースはリレーショナルデータベース技術を使用して実装できる。さらに別の例として、データベースは、オブジェクトベースのデータベース技術を使用して実装することができる。さらに別の例として、データベースは、Ｈａｄｏｏｐ分散ファイルシステム（ＨＤＦＳ）又はＡｐａｃｈｅ Ｈｉｖｅなどのクラスターストレージ技術を使用して実装できる。

【0066】

加えて又は代替的に、いくつかの実施形態では、中央監視システム１３０は、ネットワーク監視をサポートするためにネットワークトラフィックパターンのカタログを含む（及び／又はこれにアクセスする）ことができる。いくつかの実施形態では、中央監視システム１３０は、「良い」（例えば、正常及び／又は悪意のない）及び「悪い」（例えば、悪意のある及び／又は異常な）ネットワークの振る舞いの両方を表すトラフィックパターンのカタログを含む（及び／又はこれにアクセスする）ことができる。さらに、いくつかの実施形態では、中央監視システム１３０は、パターン一致を異常な（以前には見られなかった）振る舞いと区別するために使用できる情報を含む（及び／又はこれにアクセスできる）ことができる。いくつかの実施形態では、そのようなトラフィックパターンカタログは、デバイスデータベースに関連して上で説明した技術を使用して実装することができる。加えて又は代替的に、いくつかの実施形態では、そのようなトラフィックパターンカタログは、グラフデータベースを使用して実装することができる。例えば、トラフィックパターンカタログは、Ｎｅｏ４Ｊグラフデータベースプラットフォームを使用して実装することができる。別の例として、そのようなトラフィックパターンカタログは、Ｃｒａｙ Ｇｒａｐｈ Ｅｎｇｉｎｅ（ＣＧＥ）で実装できる。さらに別の例として、そのようなトラフィックパターンカタログは、グラフのような構造を扱うように構成された他の適切なスパースな、階層的な、及び／又はハイブリッドなデータストアを使用して実装できる。

【0067】

いくつかの実施形態では、中央監視システム１３０は、監視されているネットワークに関する情報のリポジトリを含む（及び／又はこれにアクセスする）ことができる。例えば、そのようなリポジトリは、ネットワークトポロジ情報を含むことができる。別の例として、そのようなリポジトリは、ネットワークに含まれるネットワークデバイス（例えば、コンピューティングデバイス）、及び／又はローカル監視デバイス１０２（及び／又は特定のローカル監視デバイス１０２）によって保護されているネットワークデバイスに関する情報を含むことができる。

【0068】

いくつかの実施形態では、中央監視システム１３０は、各ローカル監視デバイス１０２によって観察されるトラフィックパターン、及び／又は各ネットワークデバイスについて予想される振る舞いパターンへのアクセスを有することができる。いくつかの実施形態では、ネットワークに関する情報に加えて、中央監視システム１３０は、ネットワーク振る舞いのグローバル分析のために、現在及び以前のネットワークアクティビティのモデル又は複数のモデルを維持することができる。いくつかの実施形態では、モデル又は複数のモデルは、１つ又は複数のローカル監視デバイスから受け取った情報に基づいて生成することができる。例えば、中央監視システム１３０は、種々のローカル監視デバイス１０２からの正常なネットワークトラフィックのモデル及び／又はモデルに関連するデータを受け取ることができる。そのような例では、中央監視システム１３０は、正常なネットワークトラフィックのモデルを分析して、中央監視システム１３０及び／又はローカル監視デバイス１０２によって監視されているネットワークの１つ又は複数の部分で生じるパターンを識別することができる。いくつかの実施形態では、中央監視システム１３０は、分析に基づいて異なるローカル監視デバイスからの情報を合成する１つ又は複数のモデルを生成することができる。例えば、ローカル監視デバイスの多くは、監視対象のネットワークデバイスが特定のアドレス（企業のＤＮＳサーバに対応する）でリモートサーバと通信しその後すぐにトラフィックがネットワークデバイスのポート８０に送られることを示す情報を収集することができる。ネットワーク内の様々なポイントにあるローカル監視デバイスは、特定のドメイン名（例えば、ウェブサイト）に対応するＩＰアドレスの要求を表す同様のパターンを観察することができ、ＨＴＴＰコンテンツは、監視されているデバイスにポート８０を用いて送られる。別の例として、所定のローカル監視デバイスは、監視対象のネットワークデバイスが特定のポートを使用して特定のアドレスと一定間隔（例えば、デバイスがアクティブな間は１５分ごと）で通信することを示す情報を収集することができる。これは、デバイスにインストールされたアプリケーションが、アプリケーションの使用を承認するライセンスサーバに信号を送ることに対応することができる。そのような例では、中央監視デバイス１３０は、そのようなアクティビティを正常トラフィックパターンとして識別することができ、これは、アクティビティが多くの異なるネットワークデバイスで定期的に生じていることに基づいてなされる。いくつかの実施形態では、そのようなネットワークデータセット及びネットワークアクティビティのモデルは、ローカル監視デバイス１０２のデータベース及び／又はトラフィックパターンのカタログに関連して上で説明した１つ又は複数の技術を使用して実装することができる。

【0069】

いくつかの実施形態では、中央監視システム１３０は、分散ローカル監視デバイス１０２からのネットワークデータ、振る舞いパターン及び情報の多数の分析を実行することができる。いくつかの実施形態では、これらの分析は、振る舞いパターンの抽出及び比較、並びに異常検出を含むことができる。さらに、いくつかの実施形態では、これらの分析は、コミュニティ検出又は中心性分析などの任意の適切な（複数の）アルゴリズムに基づくことができる。

【0070】

いくつかの実施形態では、中央監視システム１３０は複数のインターフェースを用いて実装することができる。例えば、中央監視システム１３０は、１つ又は複数のローカル監視デバイスとの通信を容易にするネットワークインターフェースを用いて実装することができる。別の例として、中央監視システム１３０は、ＳＩＥＭシステム及び／又はネットワーク資産管理システムへの直接アクセスを容易にするインターフェースを用いて実装することができる。いくつかの実施形態では、中央監視システム１３０は、同じネットワークを監視するために実装される他のネットワーク管理及びセキュリティシステム（例えば、ＳＩＥＭ、ネットワーク資産管理システムなど）へのリアルタイムアクセスを有するように構成することができる。例えば、そのようなアクセスは、そのような他のシステムによって収集された分析データの共有を容易にすることができる。別の例として、このようなアクセスにより、セキュリティイベント通知の共有が容易になる。

【0071】

いくつかの実施形態では、中央監視システム１３０は、ユーザ（例えば、ネットワークのセキュリティを担当するユーザ）による中央監視システム１３０及び／又はローカル監視デバイス１０２の制御を容易にする１つ又は複数のインターフェースで実装することができる。例えば、中央監視システム１３０は、展開されたローカル監視デバイス１０２に関する情報を追加、消去及び／又は更新するための命令を受け入れることができるインターフェースで実装することができる。別の例として、中央監視システム１３０は、（例えば、ネットワークのセキュリティを担当するユーザによる）ローカル監視デバイス１０２のネットワーク全体の動作状態の検証及び／又は監視を容易にするインターフェースで実装することができる。いくつかの実施形態では、中央監視システム１３０は、１人以上のユーザ（例えば、ネットワークのセキュリティを担当するユーザ）による振る舞いモデリング及び／又はアルゴリズムへのアクセスを容易にするインターフェースで実装することができる。このような例では、そのようなアクセスは、ローカル監視デバイス１０２によって収集されたデータを使用するセキュリティインシデントの分析を容易にすることができる。

【0072】

いくつかの実施形態では、中央監視システム１３０は、ローカル監視デバイス１２０及び／又はコンピューティングデバイス１０４の場所の近く（ローカル）に又はそれから離れて（リモート）配置することができる。さらに、いくつかの実施形態では、中央監視システム（別の物理的位置に位置し得る）は、冗長性を提供したりロードバランシングを提供したりなどするために使用することができる。

【0073】

図２は、開示された主題のいくつかの実施形態による、図１のローカル監視デバイス、中央監視システム、及びコンピューティングデバイスを実装するために使用できるハードウェアの例を示す。図２に示されるように、いくつかの実施形態では、ローカル監視デバイス１０２は、プロセッサ２０２、ディスプレイ２０４、１つ若しくは複数の入力２０６、１つ若しくは複数の通信システム２０８、及び／又はメモリ２１０を含むことができる。いくつかの実施形態では、プロセッサ２０２は、中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）などの任意の適切なハードウェアプロセッサ又はプロセッサの組み合わせであってもよい。いくつかの実施形態では、ディスプレイ２０４は、任意の適切な（複数の）ディスプレイデバイスを含むことができる。例えば、ディスプレイ２０４は、一次元ディスプレイを使用して実装することができる。より具体的な例では、ディスプレイ２０４は、一次元ディスプレイを使用してローカル監視デバイス１０２のステータス情報を示すように各々が構成された１つ又は複数の発光ダイオード（ＬＥＤ）を使用して実装することができる（例えば、各ＬＥＤを使用して単一のステータスインジケータを示すことができ、単一のＬＥＤを使用して、１つ以上の色の一連の点滅を介してステータス情報を伝達できる）。このような例では、単一のＬＥＤを使用して、電力が供給されているか否か、特定のタイプのエラーが発生したか否かなどを示すことができる。別の例として、ディスプレイ２０４は、任意の適切な二次元ディスプレイ（例えば、７セグメントＬＥＤディスプレイ、電子ペーパーディスプレイ、有機ＬＥＤ（ＯＬＥＤ）ベースのディスプレイなど）で実装することができる。そのような例では、ディスプレイ２０４は、ローカル監視デバイス１０２に関する情報、及び／又はローカル監視デバイス１０２のステータスを提示するように構成できる。いくつかの実施形態では、ディスプレイ２０４は省略できる。

【0074】

いくつかの実施形態では、（複数の）入力２０６は、ボタン、ホール効果センサ等の、ユーザ入力を受け取るために使用できる任意の適切な（複数の）入力デバイス及び／又は（複数の）センサを含むことができる。例えば、（複数の）入力２０６を使用して、ローカル監視デバイス１０２のハードウェアリセットを実行することができる。いくつかの実施形態では、（複数の）入力２０６は省略することができる。

【0075】

いくつかの実施形態では、通信システム２０８は、通信リンク１１０，１１２及び／又は１１４を介して情報を通信するため、並びにネットワーク２０６及び／又は任意の他の適切な通信ネットワークを使用して情報を通信するための任意の適切なハードウェア、ファームウェア及び／又はソフトウェアを含むことができる。例えば、通信システム２０８は、１つ又は複数のトランシーバ、１つ又は複数の通信チップ及び／又はチップセットなどを含むことができる。より具体的な例では、通信システム２０８は、イーサネット（登録商標）接続、ＵＳＢ接続、Ｗｉ－Ｆｉ接続、ブルートゥース（登録商標）接続、セルラー接続、及び／又はその他の適切な接続を確立するために使用できるハードウェア、ファームウェア及び／又はソフトウェアを含むことができる。

【0076】

いくつかの実施形態では、メモリ２１０は、例えば、１つ又は複数のエントロピー値を生成するため、１つ又は複数のエントロピー値を格納するため、振る舞いパターン又はパターンコンポーネントを表す１つ又は複数のモデルを格納するため、ネットワークトラフィックを分析するため、（複数の）通信システム２０８を介して中央監視システム１３０と通信するためなどにローカル監視デバイス１０２を介して送られているネットワークトラフィックに関する情報を記録するためにプロセッサ２０２によって使用できる命令、値などを格納するために使用できる任意の適切なストレージデバイス又は複数のストレージデバイスを含むことができる。メモリ２１０は、任意の適切な揮発性メモリ、不揮発性メモリ、ストレージ、任意の他の適切なタイプのストレージ媒体、又はそれらの任意の適切な組み合わせを含むことができる。例えば、メモリ２１０は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、１つ又は複数のフラッシュドライブ、１つ又は複数のハードディスク、１つ又は複数のソリッドステートドライブ、１つ又は複数の光学ドライブなどを含むことができる。いくつかの実施形態では、メモリ２１０は、ローカル監視デバイス１０２の動作の少なくとも一部を制御するためのコンピュータプログラムが符号化されてもよい。いくつかの実施形態では、プロセッサ２０２は、コンピュータプログラムの少なくとも一部を実行して、監視されているネットワーク上の１つ又は複数のコンピューティングデバイスに送られた及び／又はそれから送られたネットワークトラフィックの記録を提示及び分析する、中央監視システム１３０から情報を受け取る、中央監視システム１３０に情報を送るなどすることができる。

【0077】

いくつかの実施形態では、中央監視システム１３０は、プロセッサ２１２、ディスプレイ２１４、１つ若しくは複数の入力２１６、１つ若しくは複数の通信システム２１８、及び／又はメモリ２２０を含むことができる。いくつかの実施形態では、プロセッサ２１２は、ＣＰＵ、ＧＰＵ、ＦＰＧＡ、ＡＳＩＣなどの任意の適切なハードウェアプロセッサ又はプロセッサの組み合わせとすることができる。いくつかの実施形態では、ディスプレイ２１４は、コンピュータモニタ、タッチスクリーン、テレビなどの任意の適切なディスプレイデバイスを含むことができる。いくつかの実施形態では、ディスプレイ２１４は省略することができる。いくつかの実施形態では、入力２１６は、キーボード、マウス、タッチスクリーン、マイクロフォンなどのユーザ入力を受け取るために使用できる任意の適切な入力デバイス及び／又はセンサを含むことができる。いくつかの実施形態では、入力２１６は省略することができる。

【0078】

いくつかの実施形態では、通信システム２１８は、通信ネットワーク１０６及び／又は任意の他の適切な通信ネットワークを介して情報を通信するための任意の適切なハードウェア、ファームウェア及び／又はソフトウェアを含むことができる。例えば、通信システム２１８は、１つ又は複数のトランシーバ、１つ又は複数の通信チップ及び／又はチップセットなどを含むことができる。より具体的な例では、通信システム２１８は、イーサネット（登録商標）接続、Ｗｉ－Ｆｉ接続、ブルートゥース（登録商標）接続、セルラー接続など確立するために使用できるハードウェア、ファームウェア及び／又はソフトウェアを含むことができる。

【0079】

いくつかの実施形態では、メモリ２２０は、例えば、１つ又は複数のローカル監視デバイス１０２と通信するため、ネットワークトラフィックを分析するためなどにプロセッサ２１２によって使用できる命令、値などを格納するために使用できる任意の適切なストレージデバイス又は複数のストレージデバイスを含むことができる。メモリ２２０は、任意の適切な揮発性メモリ、不揮発性メモリ、ストレージ、任意の他の適切なタイプのストレージ媒体、又はそれらの任意の適切な組み合わせを含むことができる。例えば、メモリ２２０は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、１つ又は複数のフラッシュドライブ、１つ又は複数のハードディスク、１つ又は複数のソリッドステートドライブ、１つ又は複数の光学ドライブなどを含むことができる。いくつかの実施形態では、メモリ２２０は、中央監視システム１３０の動作を制御するためのサーバプログラムが符号化されてもよい。いくつかの実施形態では、プロセッサ２１２は、コンピュータプログラムの少なくとも一部を実行して、１つ又は複数のローカル監視デバイス１０２から情報を受け取る、１つ又は複数のコンピューティングデバイス１０４に送られた及び／又はそれから送られたネットワークトラフィックを分析するなどすることができる。

【0080】

いくつかの実施形態では、コンピューティングデバイス１０４は、プロセッサ２２２、ディスプレイ２２４、１つ若しくは複数の入力２２６、１つ若しくは複数の通信システム２２８、及び／又はメモリ２３０を含むことができる。いくつかの実施形態では、プロセッサ２２２は、ＣＰＵ、ＧＰＵ、ＦＰＧＡ、ＡＳＩＣなどの任意の適切なハードウェアプロセッサ又はプロセッサの組み合わせとすることができる。いくつかの実施形態では、ディスプレイ２２４は、コンピュータモニタ、タッチスクリーン、テレビなどの任意の適切なディスプレイデバイスを含むことができる。いくつかの実施形態では、ディスプレイ２２４は省略することができる。いくつかの実施形態では、入力２２６は、キーボード、マウス、タッチスクリーン、マイクロフォンなどのユーザ入力を受け取るために使用できる任意の適切な入力デバイス及び／又はセンサを含むことができる。いくつかの実施形態では、入力２２６は省略することができる。

【0081】

いくつかの実施形態では、通信システム２２８は、通信ネットワーク１０６及び／又は任意の他の適切な通信ネットワークを介して情報を通信するための任意の適切なハードウェア、ファームウェア及び／又はソフトウェアを含むことができる。例えば、通信システム２２８は、１つ又は複数のトランシーバ、１つ又は複数の通信チップ及び／又はチップセットなどを含むことができる。より具体的な例では、通信システム２２８は、イーサネット（登録商標）接続、Ｗｉ－Ｆｉ接続、ブルートゥース（登録商標）接続、セルラー接続などを確立するために使用できるハードウェア、ファームウェア及び／又はソフトウェアを含むことができる。

【0082】

いくつかの実施形態では、メモリ２３０は、例えば、１つ又は複数のローカル監視デバイス１０２と通信するため、ネットワークトラフィックを分析するためなどにプロセッサ２２２によって使用できる命令、値などを格納するために使用できる任意の適切なストレージデバイス又は複数のストレージデバイスを含むことができる。メモリ２３０は、任意の適切な揮発性メモリ、不揮発性メモリ、ストレージ、任意の他の適切なタイプのストレージ媒体、又は任意の適切なそれらの組み合わせを含むことができる。例えば、メモリ２３０は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、１つ又は複数のフラッシュドライブ、１つ又は複数のハードディスク、１つ又は複数のソリッドステートドライブ、１つ又は複数の光学ドライブなどを含むことができる。いくつかの実施形態では、メモリ２３０は、コンピューティングデバイス１０４の動作を制御するためのサーバプログラムが符号化されてもよい。そのような実施形態では、プロセッサ２２２は、コンピュータプログラムの少なくとも一部を実行して、１つ又は複数のローカル監視デバイス１０２を介してデータを受け取る、コンテンツを提示する（例えば、ディスプレイ２２４を介して）、任意の他の適切な機能（例えば、ＣＴスキャンの実行、ＭＲＩスキャンの実行、患者の状態の監視など）を実行するなどすることができる。

【0083】

図３は、開示された主題のいくつかの実施形態による、ローカル監視デバイスを使用する分散ネットワーク監視のためのシステムのより具体的な例を示す。

【0084】

図３に示すように、イントラネットは、様々なコンピューティングデバイス及び／又はネットワークインフラストラクチャを含むことができ、様々なサブネットを含むことができる。いくつかの実施形態では、ローカル監視デバイスは、個々のネットワークシステムに接続して、及び／又はネットワークインフラストラクチャのキーポイントに配置することができる。例えば、ローカル監視デバイス１０２は、個々のネットワークシステムの監視を容易にする場所３０１に接続することができる。そのような例では、ローカル監視デバイス１０２を使用して、プリンタ又は臨床機器などのネットワークデバイスを含む個々のシステムを監視及び保護することができる。別の例として、ローカル監視デバイス１０２は、ルーティングインフラストラクチャとネットワークの上流部分との間の場所３０２において接続することができる、及び／又はスイッチポートアナライザ（ＳＰＡＮ）ポート若しくは他の監視ポートに接続することができる。このような例では、ネットワーク機器（ルータなど）にＳＰＡＮ又は監視ポートが実装されている場合、ローカル監視デバイスをそのようなポートに接続できる。ただし、これは単なる例であり、ネットワーク機器の上流側に送られる及び／又はそこから送られるすべてのトラフィックを傍受するようにローカル監視デバイスを接続することができる。ＳＰＡＮ又は監視ポートへの接続は、必ずしも「ｂｕｍｐ ｉｎ ｔｈｅ ｗｉｒｅ」構成である必要はないが、ＳＰＡＮ又は監視ポートで特定のトラフィックのみを示すようにルータを構成することで柔軟性を高めることができることに留意すべきである。

【0085】

別の例として、ローカル監視デバイス１０２は、ネットワーク内のキーポイント３０３、例えば（例えば、ネットワークに接続している無線デバイス３６２を監視するために）無線アクセスポイント３６０の上流などにおいて、データセンター３１２内のネットワークルータ３６４及び／又は他のネットワークインフラストラクチャ（例えば、１つ又は複数のサーバ３５４、１つ又は複数のスーパーコンピュータ３６３など）の間で、１つ又は複数のファイアウォールアクセス制御ポート３２１を監視するためにファイアウォール３２０を実装するネットワークデバイスに接続することができる。ネットワークルータは単なる例であり、ローカル監視デバイスは、ネットワークブリッジ、スイッチ、リピータ、及び／又は、ツリー、スター、リング若しくは通信ネットワーク全体の通信と相互接続を容易にするためのその他のトポロジの接続に使用されるその他のデバイスなどの、他のタイプのネットワークインフラストラクチャデバイスに関連付けることができることに留意すべきである。

【0086】

いくつかの実施形態では、ローカル監視デバイス１０２をネットワーク内の異なるポイントにおける場所（例えば、場所３０１，３０２及び／又は３０３）に配置することにより、特定のデバイス（例えば、ソフトウェアによって効率的に保護することができないデバイス）のトラフィックパターンの監視からネットワークの大部分へのトラフィックパターンの監視まで容易にすることができる。例えば、医療機器３７１又はコンピューティングデバイス３７２（例えば、ローカル管理ワークステーション）などの個々のネットワークデバイスに関連して場所３０１に配置されたローカル監視デバイス１０２は、それらのデバイスへの及び／又はそれらのデバイスからのトラフィックの監視を容易にすることができ、ネットワーク内の別の場所（又は別のネットワーク内である可能性がある）にある他の同様のデバイスによる振る舞いを分類するために使用できる、これらのデバイスによる振る舞いのモデルを生成することができる。

【0087】

別の例として、ルータ３６４などのネットワークインフラストラクチャに関連して場所３０２に配置されたローカル監視デバイス１０２は、ルータ３６４によってデバイスへ送られる及び／若しくはデバイスから送られるトラフィックの監視を容易にすることができ、並びに／又は、ネットワーク（サブネットなど）の全体部分のモデルを生成するために使用することができる。より具体的な例では、場所３０２に配置されたローカル監視デバイス１０２を使用して、部門ＬＡＮ３１５、医療機器ゾーン３１４、及び／又はネットワークの他の適切な部分を監視することができる。

【0088】

さらに別の例として、無線アクセスポイント３６０、データセンター３１２、ファイアウォール３２０、及び／又は任意の他の適切なキーポイントなどのネットワーク内のキーポイントに関連する場所３０３に配置されたローカル監視デバイス１０２を使用して、そのようなキーポイントを通過するトラフィックのモデル、例えば、１つ又は複数の外部中継接続３５０を介してインターネット３１０へ及び／若しくはインターネット３１０から伝送されているデータ、ファイアウォールアクセス制御ポート３２１を介して伝送されているデータ、ファイアウォールゾーン３１１（非武装地帯と呼ばれることもある）内で伝送されているデータ、並びに／又は、ネットワークの他の部分を介して伝送されているトラフィックなどのトラフィックのモデルを生成することができる。

【0089】

上述したローカル監視デバイスを配置できる場所は、ローカル監視デバイスを配置できる場所の単なる例であることに留意すべきである。ローカル監視デバイスは、ネットワーク内の任意のリンク及び／又はネットワークの任意のノードからの任意のリーフ相互接続に接続して配置できる。

【0090】

図４は、開示される主題のいくつかの実施形態による、ローカル監視デバイスを使用してネットワークの一部を監視するためのプロセスの例を示す。４０２において、プロセス４００は、監視対象ネットワーク上の特定のコンピューティングデバイスに送られた及び／又はこれから送られたネットワークトラフィックを受け取ることができる。

【0091】

４０４において、プロセス４００は、ネットワークトラフィックに基づいて１つ又は複数のメトリックを計算することができる。例えば、プロセス４００は、ネットワークトラフィックの１つ又は複数の特性に関連するエントロピーを計算することができる。ネットワークトラフィックメタデータは、エントロピーの計算に使用できる比較的大きなパラメータセットを提供する。このようなパラメータの例は、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート（送信元ポート及び／又は宛先ポートは特定のアプリケーションに関連付けられていることが多いことに留意すべきである）、パケットサイズ（例えば、バイト単位、ビット単位）、トラフィックの量（例えば、経時的なパケット数、経時的なビット数、経時的なバイト数）、プロトコルの種類、プロトコル固有のフラグ及び／又は特徴などをとりわけ含むことができる。

【0092】

エントロピーは、シンボルのセットで情報量を記述するために使用でき、一般的な（予想される）セットと普通でない（異常な）セットを区別するのに有用な方法である。確率質量関数Ｐ（Ｘ）との関連における、可能な値｛ｘ_１，…，ｘ_ｎ｝を有する離散型確率変数Ｘのシャノン定義エントロピーΗ（この記号は英語の文字Ｈではなくエータ（Ｅｔａ）であることに注意すべきである）は、次の式を用いて表すことができる。

【0093】

【数1】

【0094】

対数の底ｂが２に等しい場合、エントロピーの単位は「シャノン」と呼ばれ、しばしばビットと呼ばれることに留意すべきである。いくつかの実施形態では、エントロピーモデルは、確率質量関数に関するネットワークトラフィックの周期的な性質（例えば、コア営業時間外のトラフィックの減少）を考慮しつつ、特定の期間（例えば、１分、１０分、３０分、１時間、２時間、１２時間、１日、又は他の適切な期間）内に観察されたデータに基づくことができる。いくつかの実施形態では、所定の期間が経過した後にモデルをリセットすることができる。そのような実施形態では、各期間にわたって蓄積されたデータに基づいてエントロピーを計算することができる。

【0095】

いくつかの実施形態では、プロセス４００は、比較的シンプルなエントロピーモデルを使用してネットワークトラフィックを特徴付けることができる。例えば、プロセス４００は、エントロピー値を（例えば式（１）に基づいて）１つ又は複数のパラメータに対して独立して決定することができる。そのような例では、ネットワークトラフィックを特徴付けるために使用されるパラメータは、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、バイト数、使用されているプロトコルに関する情報など、任意の適切なパラメータを含むことができる。いくつかの実施形態では、各パラメータのエントロピー値は、経時的に比較的一定であると予想できるが、異常な振る舞いによりエントロピーが大幅に変化する可能性がある。

【0096】

いくつかの実施形態では、プロセス４００は、より複雑なエントロピーモデルを使用してネットワークトラフィックを特徴付けることができる。例えば、プロセス４００は、追加のパラメータを用いて（例えば、複数のパラメータの同時確率に基づき）条件付きエントロピーを使用することができ、及び／又は、エントロピー値の集合を使用することができる。

【0097】

特定の例では、ローカル監視デバイス１０２を使用して、通常は３台のプリンタ及び１０個のクライアント（例えば、コンピューティングデバイス１０４）と通信するネットワークプリントサーバを監視することができる。日々、そのプリントサーバからのトラフィックの宛先アドレスのエントロピー（又は情報コンテンツ）は、プリントサーバに送られる及びそこから送られるトラフィックの量に関係なく比較的安定していることが期待できる。非常に忙しい日であっても、トラフィック量が増加しても宛先アドレスの情報内容は同じである。プリンタが交換された場合、宛先アドレスのエントロピーは一時的に増加し得るが、他のパラメータのエントロピーは安定している可能性がある。ただし、プリントサーバがマルウェアに感染しネットワーク偵察に使用された場合、マルウェアがプリントサーバに、プリントサーバが通常は通信しない他のネットワークシステムをプローブさせる可能性がある。これにより、いくつかのエントロピー値が変更されることが予想される。このような例では、マルウェアによって引き起こされる追加の通信により、別の宛先アドレスの数が増加する可能性が高く、そのような新しい情報によって宛先アドレスのエントロピー値が急上昇する可能性がある。同様に、他のシステムをプローブするために送られるパケットのサイズ（例えば、バイト単位）と、使用されるプロトコルとは、均一である可能性があり、これにより他のエントロピー値（期待値からのエントロピーの変化も表する）が低下する可能性がある。

【0098】

別のより具体的な例として、入ってくるネットワークトラフィックがＭａｙｏネットワーク上の単一のウェブサーバについて分析された。ネットワークメタデータは、特定のウェブサーバが１０分ごとに約８，０００個のフローを受け取ったことを示し、それらはウェブサービス要求及びＳＱＬデータベースサーバとの対話によって支配されていた。各フローレコードは、ネットワークトラフィックの概要（単にメタデータと呼ばれることもある）を含むことができ、そして、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、通信プロトコル（例えば、ＴＣＰ、ＵＤＰ）、バイト数、期間、フラグなどを含むことができる。メタデータパラメータのエントロピーは、５時間にわたって１０分ごとに計算されて、各パラメータのエントロピー値の時系列が作成された。ポート番号やアドレスなどのデータについては、それぞれが発生したフローの数がカウントされ、これはハッシュテーブルを介して実装できる。数値データ（例えば、バイト）は、エントロピーの計算に使用するために、期間にわたって蓄積することができる。分析されたパラメータには、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、プロトコル、ＴＣＰフラグ、各フローのバイト数（例えば、全パケットにわたる）、各フローのパケット数、及びフロー期間（例えば、秒単位）が含まれていた。別のサーバからのトラフィックレコードをデータにコピーすることにより、１２：００に意図的に異常が導入された。図７において、正常な振る舞いと異常とが統計的工程管理（ＳＰＣ）管理限界を使用して±３標準偏差でプロットされている。異常は、１２：００にて、９つのパラメータのうち７つに検出され、ただし図７では、図が過密になるのを避けるために５つのパラメータのみが示されている。

【0099】

上記の例では、送信元ＩＰアドレスの異常は、分散型サービス妨害（ＤＤｏＳ）攻撃で見られる場合があるように、入ってくるトラフィックの多様性が急激に増加したことを示す。エントロピーモデルは離散的な確率分布を計算するため、特定のネットワークパケット又はフローの確率（又はあり得なさ）を調べることができる。

【0100】

この例では、様々なトラフィックメタデータパラメータへのエントロピーのシンプルな適用が使用されていることに留意されたい。しかしながら、条件付きエントロピー、Ｔｓａｌｌｉｓエントロピー及び／又は階層的分類スキームなどの、エントロピーの他のより複雑な実施形態を使用することができる。一時的な特徴や、ペイロードデータ自体のエントロピーなどの、追加のパラメータも考慮することができる。

【0101】

どの（複数の）パラメータを分析するか、及び／又はどの特定のエントロピー計算を使用するかの選択に関係なく、数学と基本的なハードウェアの実装は同様であると予想できることに留意されたい。エントロピーの計算には、値の確率分布若しくはヒストグラム、加算、乗算、及び対数演算が必要であり、これらはすべて、比較的小さな「ドングル」などのコンパクトな物理ハードウェアフォームファクターにおいて実行することができる。この機能は、適切なテクノロジー又は複数のテクノロジーを使用して実装することができる。ただし、ＦＰＧＡやＡＳＩＣを使用してエントロピーの計算及び／又は比較を実行するハードウェアを実装することにより、フォームファクターの小型化が容易になり、何故なら、そのようなハードウェアは一般に、同じ機能を実装するために必要な電力、スペース及び部品が少なくて済むからである。メモリ要件は、ヒストグラムのサイズ（例えば、ビン単位、ビン当たりカウント数）、及びエントロピーが追跡されるパラメータの数に依存し得る。

【0102】

メタデータ異常検出は、プロセス４００によって４０４において実行できる機能の単なる例であることに留意されたい。いくつかの実施形態では、確率分布の観点からネットワークトラフィックを特徴付けることにより、ネットワークデバイスの振る舞いのコンパクトで表現に富むモデルを容易にすることができる。例えば、ローカル監視デバイス及び／又は中央監視システムの間でモデルを交換及び比較することで、進化する無害な振る舞い及び生まれてくる脅威アクティビティの迅速な拡散を容易にすることができる。別の例として、ローカル監視デバイスは、ネットワークの周辺近くに配置することにより、（例えば、４１２に関連して以下で説明するように）ネットワーク内の多くのポイントでディープパケット検査を実行することができる。

【0103】

加えて又は代替的に、４０６において、いくつかの実施形態では、プロセス４００は、１つ又は複数のシンプルなグラフメトリックを計算することができる。このようなメトリックの例は、入次数（ｉｎ－ｄｅｇｒｅｅ）及び出次数（ｏｕｔ－ｄｅｇｒｅｅ）を含むことができる。いくつかの実施形態では、プロセス４００は、媒介中心性などの１つ又は複数の比較的複雑なグラフメトリックを計算することができる。次数のカウントには、ユニークな送信元及び宛先アドレスを追跡するテーブル（又はハッシュテーブル又は辞書）が必要である。テーブルのサイズは、ネットワークノードの数及びトラフィックパターンによって異なる。同じデータ構造を使用して、媒介中心性などの複雑なグラフメトリックを計算することができる。留意すべきことに、このようなグラフメトリックはソフトウェアに実装でき、又はハードウェアロジックを使用して実装でき（例えば、ＦＰＧＡ及び／又はＡＳＩＣを使用して）、これにより、（例えば、中央監視システム、又は高価な専用ネットワークプローブを使用してそのような計算を実行するのではなく）比較的小さなフォームファクターのローカル監視デバイスを使用してそのようなメトリックの計算を容易にすることができる。

【0104】

４０６において、４０６で計算されたメトリックを、「正常な」トラフィックのモデルに基づくメトリックの期待値と比較することができる。例えば、プロセス４００は、（例えば、ある期間にわたって観察されたメトリック値の分布に基づいて）特定のメトリックについての期待値の範囲を計算することができ、そして、プロセス４００は、特定の通信（例えば、個々のパケット、パケットのフロー）についての、又は特定の期間中の（例えば、１分、２分、５分、１０分などの間隔で集計された値に基づく）メトリック値を比較することができる。

【0105】

いくつかの実施形態では、範囲は、特定の時間にわたる（例えば、過去１２時間にわたる、最終日にわたる、先週にわたる、「正常」と見なされた特定の１２時間のスパンにわたる、「正常」と見なされた特定の日にわたる）メトリックの値の標準偏差に基づいて計算することができる。例えば、範囲は、平均値のいずれかの側の標準偏差１つ分の範囲とすることができる。別の例として、範囲は、平均値の両側の標準偏差２つ分の範囲とすることができる。さらに別の例として、範囲は、平均値のいずれかの側の標準偏差３つ分の範囲とすることができる。

【0106】

４０８において、プロセス４００は、１つ又は複数の適切な基準に基づいて異常が検出されたか否かを判断することができる。例えば、パラメータのしきい値数（例えば、２、３などの特定の数、又は３分の１、半分、３分の２などの特定の分数）が、正常と見なされる範囲から逸脱する値を生成する場合、プロセス４００は、異常が検出されたと判断することができる。別の例として、値の特定の組み合わせ（又は複数の組み合わせ）が正常と見なされる範囲（例えば、宛先アドレス、及びパケットサイズ）から逸脱する場合、プロセス４００は、異常が検出されたと判断することができる。

【0107】

異常が検出されなかったとプロセス４００が判断した場合（４０８で「いいえ」）、プロセス４００は４０２に戻って追加のネットワークトラフィックを受け取ることができる。そうではなく、異常が検出されたとプロセス４００が判断した場合（４０８で「はい」）、プロセス４００は４１０に移動することができる。

【0108】

４１０において、プロセス４００は、異常が発生したことを中央監視システムにレポートすることができる。いくつかの実施形態では、レポートは、異常が検出された時間、異常なトラフィックを受け取った期間、（例えば、４０６において）正常であるとみなされる範囲を逸脱すると判断された１つ又は複数のメトリックの識別情報などの、任意の適切な情報を含むことができる。

【0109】

４１２において、プロセス４００は、４０２においてネットワークトラフィックの一部として受け取った１つ又は複数のパケットを分析することができる。いくつかの実施形態では、任意の適切な手法又は手法の組み合わせを使用してパケットを分析することができる。例えば、プロセス４００は、１つ又は複数のディープパケット検査（ＤＰＩ）手法を使用してパケットを分析することができる。ディープパケット検査手法の例としては、正規表現を使用するパターンマッチングが挙げられる（例えば、ウイルス対策ルールセットについて、及びＳｎｏｒｔベースのネットワーク侵入検出ルールセットについて）。別の例として、プロセス４００は、訓練された機械学習モデルを使用してパケットを分析することができる。さらに別の例として、コンテキストアウェア異常検出手法を使用して、アプリケーション層でゼロデイ攻撃を識別しようとすることができる（例えば、参照によりその全体が本明細書に盛り込まれている、Ｄｕｅｓｓｅｌらによる「Ｄｅｔｅｃｔｉｎｇ Ｚｅｒｏ－ｄａｙ Ａｔｔａｃｋｓ ｕｓｉｎｇ ｃｏｎｔｅｘｔ－ａｗａｒｅ ａｎｏｍａｌｙ ｄｅｔｅｃｔｉｏｎ ａｔ ｔｈｅ Ａｐｐｌｉｃａｔｉｏｎ－ｌａｙｅｒ」，Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ，ｐｐ．１－１６（２０１６）に記載されている）。

【0110】

一般に、ＤＰＩはネットワーク内の脅威を識別するための強力なツールである。ただし、ＤＰＩは比較的高い計算資源を必要とする可能性があるため、例えばファイアウォール又はアプリケーションアプライアンスなどの、すべてのウェブトラフィック又は受信メールを評価し得るネットワーク上のいくつかのポイントのみに限定されることが多い。

【0111】

ＤＰＩは通常はネットワーク内に広く展開されてはないが、多くのネットワークシステム（例えば、コンピューティングデバイス１０４など）でマルウェア保護（例えば、ウイルススキャン）ソフトウェアを必要とするのが一般的である。これらのシステム上の静的ファイルをスキャンすることに加えて、マルウェア保護ソフトウェアは、多くの場合、電子メールなどの特定のアプリケーショントラフィックを監視する。この計算集約的なタスクは、通常、多くのシステムに分散されることによってのみ可能であり、これにより実質的に並列処理システムが形成される。

【0112】

いくつかの実施形態では、プロセス４００は、多くのローカル監視デバイス（例えば、ローカル監視デバイス１０２）で実行することができ、１つ又は複数のＤＰＩ手法を適用して、そのローカル監視デバイスによって監視されているネットワークの限られた部分を横断するすべてのパケットをスキャンすることができる。例えば、１つ又は比較的少数のコンピューティングデバイス（例えば、「ｂｕｍｐ ｉｎ ｔｈｅ ｗｉｒｅ」デバイス）を監視するために展開されたローカル監視デバイスは、それを通過するすべてのパケットのすべてのバイトをスキャンできる。大規模ネットワークプローブ、ファイアウォール、サーバ、及び多くのパーソナルコンピュータと比較すると、各ローカル監視デバイスの計算資源は限られているが、そのようなローカル監視デバイスは、（例えば、ソフトウェア、ファームウェア、及び／又はＦＰＧＡ又はＡＳＩＣを介して）限られたスキャン機能を（例えば、少数のＤＰＩ手法のみを実装することによって、パケットが比較されるルールセットを制限することによって）実行するようプログラムされてもよい。このタイプの実装は、このようなスキャンを異常検出及び／又はその他の機能と並行して実行することを容易にし、従来のＤＰＩインストールでは見えない可能性があるトラフィックペイロードをスキャンするように構成された並列処理スキャンエンジンを形成し、ウイルススキャンソフトウェアを実行できないシステムを保護するために使用することができる。ローカル監視デバイスが特定のコンピューティングデバイスに直接接続され、上流のネットワークインフラストラクチャデバイスに接続されている場合など（例えば、１つのローカル監視デバイスを医療機器に直接接続することができ、別のローカル監視デバイスを上流のルータに接続することができる）のいくつかの実施形態では、異なるローカル監視デバイスは、コンピューティングデバイスに提供される保護を強化するために、異なる（例えば、オーバーラップしない）スキャンを実行するように構成することができる。いくつかの実施形態では、暗号化されていない通信にアクセスできるローカル監視デバイスは、ＤＰＩを実行するように構成でき、一方、暗号化された通信のみにアクセスできるローカル監視デバイスは、ＤＰＩを実行しないように構成できる。

【0113】

４１４において、プロセス４００は、４１２において実行された分析の結果に基づいて、特定のパケットが悪意のあるものか否かを判断することができる。例えば、プロセス４００は、悪意のあるアクティビティ（マルウェアなど）に関連する署名とマッチする署名を有するパケットのコンテントに基づいて、特定のパケットが悪意のあるものと判断することができる。別の例として、プロセス４００は、悪意のないアクティビティ（例えば、正常なアクティビティ）に関連する署名とマッチしない署名を有するパケットのコンテンツに基づいて、特定のパケットが悪意のあるものと判断することができる。

【0114】

プロセス４００が、パケットが悪意のある可能性が高いと判断しなかった場合（４１４で「いいえ」）、プロセス４００は４０２に戻ることができる。そうでない場合、プロセス４００が、パケットが悪意のある可能性が高いと判断した場合（４１４で「はい」）、プロセス４００は４１６に移動できる。

【0115】

４１６において、プロセス４００は、悪意のあるパケットが検出されたことを中央監視システムにレポートすることができる。いくつかの実施形態では、レポートは、パケットが受け取られた時間、ディープパケット検査の結果（例えば、４１２での分析の結果）などの任意の適切な情報を含むことができる。

【0116】

いくつかの実施形態では、４０４から４０８は、４１２から４１６と並行して実行することができる。

【0117】

４１８において、プロセス４００は、異常及び／又は悪意のある可能性があるパケットに関連するネットワークトラフィック及び／又は他の情報を中央監視システムに提供することができる。例えば、いくつかの実施形態では、プロセス４００を実行するデバイスは、特定の期間にわたって４０２で受け取られたすべてのネットワークトラフィックを格納させることができ、異常が検出されたときにそのようなネットワークトラフィックを中央監視システムに提供することができる。加えて又は代替的に、いくつかの実施形態では、プロセス４００を実行するデバイスは、特定の期間にわたって４０２で受け取られたすべてのネットワークトラフィックに関連するメタデータを格納させることができ、異常が検出されたときにそのようなメタデータを中央監視システムに提供することができる。そのようなメタデータは、異常に対応する期間及び／又は以前の期間にわたるエントロピー及び／又は１つ若しくは複数の他のメトリックを生成するために使用される集約されたメタデータを含むことができる。

【0118】

いくつかの実施形態では、プロセス４００を実行するデバイスは、特定の期間にわたって４１２で分析されたパケットを格納させることができ、パケットが悪意のある可能性が高いと検出されたときに、１つ又は複数のパケットを中央監視システムに提供することができる。

【0119】

いくつかの実施形態では、検出がネットワーク周辺で実行されるため、レポートはコンパクトかつタイムリーにすることができる。異常検出の場合、監視により、アラームを発生させたネットワークデータと、異常の判断の対象のバックグランドを定める（複数の）異常モデル（例えば、ヒストグラムの形式）との両方をレポートできる。対照的に、他のレポートシステムでは、分析を実行する前に大量のデータを中央分析システムに転送する必要があり、そのデータが格納されて分析のために準備されるため、かなりの遅延が発生する可能性がある。

【0120】

４２０において、プロセス４００は、監視されているネットワークの一部を介して通信を保護するためのアクションを起こすことができる。いくつかの実施形態では、プロセス４００は、４０６及び／又は４１２での結果に基づいてそのようなアクションを開始することができる。加えて又は代替的に、いくつかの実施形態では、プロセス４００は、中央監視システム（例えば、中央監視システム１３０）からの命令に応答してそのようなアクションを開始することができる。

【0121】

いくつかの実施形態では、プロセス４００を実行するデバイスは、様々な複雑さとリスクを伴ってネットワークトラフィックに能動的に影響を与えることができる。例えば、プロセス４００を実行するデバイスは、中央監視システムによって命令されたときに、（例えば、特定のアドレスからの、特定のアドレスへの、特定のポートからの、特定のポートへの）トラフィックを能動的にブロックすることができる。より具体的な例では、分散型サービス妨害攻撃が検出された場合、中央監視システムは、プロセス４００を実行する１つ又は複数のローカル監視デバイスに、レポートする（例えば、異常又は悪意のあるアクティビティが検出されたか否かに関わらず４１８においてトラフィック及び／又は他の情報を提供する）及び／又は特定の脅威パターンにマッチするトラフィックをブロックするように命令することができる。別の例として、プロセス４００を実行するデバイス（例えば、ローカル監視デバイス１０２）は、４１０、４１６及び／又は４１８においてレポートすること、及び、極めて異常であると考えるトラフィックをブロックするためのアクションを起こすことの両方を行うことができる。このような例では、高レベルネットワークプロトコルの「リトライ」機能を利用して、正当なトラフィックのブロックからの回復をすることができる。

【0122】

図４に関連して上で説明したプロセス４００は、異常な及び／又は悪意のある可能性があるトラフィックを識別するために使用できるプロセスの一例に過ぎず、プロセス４００は、（例えば、４０４から４１０に関連して説明したような）モデルを使用した異常検出及び／又は（例えば、４０４から４１０に関連して説明したような）ディープパケット検査手法を使用した悪意のあるパケットの識別に加えて、あるいはその代わりに、他の手法を使用することができる。例えば、いくつかの実施形態では、プロセス４００は、ネットワークトラフィック及び／又はネットワークトラフィックに関連するメタデータを、明示的に許可するアドレス及び／又は明示的に許可しないアドレスのリストと比較することができる。より具体的な例では、プロセス４００は、アドレスが明示的に許可しないアドレスのリストにあるとプロセス４００が判断した場合、ネットワークトラフィックが悪意のある可能性があるものと判断することができる。別のより具体的な例として、プロセス４００は、アドレスが明示的に許可するアドレスのリストにないとプロセス４００が判断した場合、ネットワークトラフィックが悪意のある可能性があるものと判断することができる。さらに別のより具体的な例として、プロセス４００は、アドレスが明示的に許可しないアドレスのリストにないとプロセス４００が判断した場合、ネットワークトラフィックが悪意のないものと判断することができる。

【0123】

別の例として、プロセス４００は、ネットワークトラフィック及び／又はネットワークトラフィックに関連するメタデータを、ネットワークトラフィックの時間パターンに基づく時間モデルと比較することができる。特定の例では、プロセス４００は、ネットワークトラフィックが時間モデルによって表されるトラフィックとマッチしない場合、ネットワークトラフィックが悪意のある可能性があるものと判断することができる。別の特定の例として、プロセス４００は、ネットワークトラフィックが時間モデルによって表されるトラフィックとマッチする場合、ネットワークトラフィックが悪意のないものと判断することができる。さらに別のより具体的な例として、時間モデルは悪意のあるアクティビティのモデルであってもよく、プロセス４００は、ネットワークトラフィックが時間モデルによって表されるトラフィックとマッチする場合、ネットワークトラフィックが悪意のあるものと判断することができる。さらに別のより具体的な例として、時間モデルは悪意のあるアクティビティのモデルであってもよく、プロセス４００は、ネットワークトラフィックが時間モデルによって表されるトラフィックとマッチしない場合、ネットワークトラフィックが悪意のないものと判断することができる。

【0124】

さらに別の例として、プロセス４００は、ネットワーク上のスキャンアクティビティに基づくモデルに関連するネットワークトラフィック及び／又はメタデータを比較することができる。特定の例では、プロセス４００は、ネットワーク上のスキャンアクティビティに基づくモデルにネットワークトラフィックがマッチしない場合、ネットワークトラフィックが悪意のある可能性があるものと判断することができる。別の特定の例として、プロセス４００は、ネットワーク上のスキャンアクティビティに基づくモデルにネットワークトラフィックがマッチする場合、ネットワークトラフィックが悪意のないものと判断することができる。さらに別のより具体的な例として、ネットワーク上のスキャンアクティビティに基づくモデルは、悪意のあるスキャンアクティビティのモデルとすることができ、プロセス４００は、ネットワークトラフィックがネットワーク上のスキャンアクティビティに基づくモデルとマッチする場合、ネットワークトラフィックが悪意のあるものと判断することができる。さらに別のより具体的な例として、ネットワーク上のスキャンアクティビティに基づくモデルは、悪意のあるアクティビティのモデルとすることができ、プロセス４００は、ネットワークトラフィックがネットワーク上のスキャンアクティビティに基づくモデルとマッチしない場合、ネットワークトラフィックが悪意のないものと判断することができる。

【0125】

図５は、開示された主題のいくつかの実施形態による、ローカル監視デバイスから受け取ったネットワークデータに基づいて悪意のある可能性があるアクティビティを検出するためのプロセスの例を示す。５０２において、プロセス５００は、ローカル監視デバイスからデータを受け取ることができる。例えば、プロセス５００は、４１０及び／又は４１６においてローカル監視デバイスによって送られたレポート、並びに４１８においてローカル監視デバイスによって送られたネットワークトラフィック及び／又は他の情報を受け取ることができる。

【0126】

５０４において、プロセス５００は、受け取ったデータを分析して、データが悪意のある可能性があるアクティビティを表しているか否かを判断することができる。例えば、いくつかの実施形態では、プロセス４００は、４０６において特定のトラフィックが異常である可能性が高いか、又は４１２において悪意のある可能性が高いと判断することができ、レポートを生成して、（複数の）判断を行うために使用された情報を送ることができる。５０４において、プロセス５００は、アラートを発生させたトラフィックが悪意のあるものである可能性が高いか否かの検証を試みることができる。例えば、プロセス５００は、ネットワークアクティビティを、他のローカル監視デバイスからのモデルと及び／又はネットワークのより広い部分にわたるトラフィックパターンと比較して、特定のローカル監視デバイスが異常なトラフィックとしてレポートしたトラフィックが他のネットワークトラフィックと比較して異常であるか否かを判断することができる。別の例として、プロセス５００は、プロセス４００によって悪意のある可能性があると識別されたパケットに対して、より高度なＤＰＩ手法を実行する（又は実行させるようにする）ことができる。

【0127】

５０６において、プロセス５００が、アクティビティが悪意のあるものである可能性が低いと判断した場合（５０６において「いいえ」）、プロセス５００は５０２に戻ることができる。そうでなければ、プロセス５００が、アクティビティが悪意のあるものである可能性が高いと判断した場合（５０６において「はい」）、プロセス５００は５０８に進むことができる。

【0128】

５０８において、プロセス５００は、ローカル監視デバイスに関連するネットワークの１つ又は複数の部分を介する通信を保護するための適切なアクションを起こすことができる。例えば、４２０に関連して上で説したように、プロセス５００は、１つ又は複数のローカル監視デバイスに、特定の脅威パターンに適合するトラフィックをブロックするように命令することができる。別の例として、プロセス５００は、特定されたリスクを示すアラートをユーザ（例えば、ネットワーク管理者などのネットワークのセキュリティを担当するユーザ）に提示させることができる。

【0129】

図６は、開示された主題のいくつかの実施形態による、ローカル監視デバイスから受け取ったネットワークトラフィックのモデルに基づいて悪意のある可能性があるアクティビティを検出するためのプロセスの例を示す。６０２において、プロセス６００は、ローカル監視デバイスからネットワーク振る舞いのモデルを受け取ることができる。例えば、そのようなモデルは、（例えば、図４に関連して上で説明したような）経時的なエントロピー計算及び／又は経時的なネットワークトラフィック統計に基づくことができる。

【0130】

６０４において、プロセス６００は、６０２において受け取ったモデルを分析して、モデルが悪意のある可能性があるアクティビティを表しているか否かを判断することができる。例えば、プロセス６００は、６０２において受け取ったモデルを、他のローカル監視デバイスから受け取った１つ若しくは複数のモデルと、及び／又は、複数のローカル監視デバイスにわたる集計されたネットワークトラフィックに基づいてプロセス６００を実行するデバイス（例えば、中央監視デバイス１３０）によって生成されたモデルと比較することができる。いくつかの実施形態では、６０４における比較に使用される（複数の）モデルは、同様のデバイスへのトラフィックを表すモデルから選択することができる。

【0131】

６０６において、プロセス６００は、６０４における比較に基づいて、モデルが悪意のある可能性があるアクティビティを表しているか否かを判断することができる。例えば、モデルの１つ又は複数の特徴が、比較対象のモデルから大幅に逸脱している場合、プロセス６００は、６０２において受け取った「正常」モデルが、進行中の悪意のあるアクティビティを表している可能性があると判断することができる。

【0132】

プロセス６００が、モデルが悪意のあるアクティビティを表していない可能性が高いと判断した場合（６０６において「いいえ」）、プロセス６００は６０２に戻ることができる。そうでなければ、プロセス６００が、モデルが悪意のあるアクティビティを表している可能性が高いと判断した場合（６０６において「はい」）、プロセス６００は６０８に移動することができる。

【0133】

６０８において、プロセス６００は、ローカル監視デバイスに関連するネットワークの１つ又は複数の部分を介する通信を保護するための適切なアクションを起こすことができる。例えば、４２０に関連して上で説明したように、プロセス６００は、１つ又は複数のローカル監視デバイスに、特定の脅威パターンに適合するトラフィックをブロックするように命令することができる。別の例として、プロセス６００は、特定されたリスクを示すアラートをユーザ（例えば、ネットワーク管理者などのネットワークのセキュリティを担当するユーザ）に提示させることができる。

【0134】

図７は、開示された主題のいくつかの実施形態による、ローカル監視デバイスによる異常検出に使用できる経時的なエントロピーの例を示す。図７に示すように、入ってくるネットワークトラフィックが、Ｍａｙｏネットワーク上の単一のウェブサーバについて分析された。別のサーバからのトラフィックレコードをデータにコピーすることにより、１２：００に意図的に異常が導入された。図７において、正常な振る舞いと異常とが統計的工程管理（ＳＰＣ）管理限界を使用して±３標準偏差でプロットされている。図７において部分的に示されているように、異常は、１２：００にて、９つのパラメータのうち７つに検出された。

【0135】

図８Ａから図８Ｃは、組織イントラネット内の様々なシステムのそれぞれにおけるサブネットの数のプロットを、それぞれ、線形軸、対数目盛が付いたｙ軸、及び両対数軸で示す。開示された主題のいくつかの実施形態にしたがってローカル監視デバイスが実装する、処理の必要がある可能性があるデータの量を定量化するために、Ｍａｙｏイントラネットから取り込まれたメタデータが評価された。メタデータは、通常の営業日の１時間のネットワークアクティビティから取り込まれたものであり、追加の１７０，０００個の外部システムと通信する２１０，０００個を超える内部アドレスを含んでいた。平均ネットワーク負荷は毎秒１７００万パケットで、毎秒１２ＧＢのデータを伝送していた。ルータは、毎秒２１０，０００個をわずかに超えるフロー（メタデータレコード）をレポートした。支配的なネットワークプロトコルはＴＣＰ（７０％）及びＵＤＰ（２３％）であり、送信元及び宛先アドレスとポートの個別の組み合わせが１億４０００万個以上あった。

【0136】

Ｍａｙｏネットワークは論理的に３，３８４個のサブネットワークに分割され、これにより、マップがネットワークルーティングインフラストラクチャに提供される。ネットワークの論理構造と、様々なサブネットワーク上のトラフィックの量及び品質との両方が分析されて、比較的大規模で複雑なネットワーク環境で予想されるデータ量の例が示された。

【0137】

単一のネットワークシステムに接続されたローカル監視デバイスは、サブネットワーク全体ではなく、接続されたシステムについてのみデータを処理することが期待できることに留意すべきである。したがって、異常は、ローカル監視デバイスが接続されているネットワークシステムの正常な振る舞いに関してのみ検出できる。そのような例では、シンプルなネットワークグラフメトリック（例えば、出次数）は、トラフィック内のユニークなアドレスをカウントするだけで計算できるが、単一システムレベルでは、より複雑なグラフ分析は多くの場合不可能である。

【0138】

所与のサブネット上のシステムの数は、サブネット全体を監視するように実装される場合ローカル監視デバイスがしなければならない作業の量に影響を与える可能性がある。分散は一様ではなく、少数のサブネットが数千のシステムをサポートしている一方で、大多数のシステムは数十のシステムしかサポートしていない。サブネット上のシステムの数は、ネットワークインフラストラクチャに接続されるローカル監視デバイスのメモリ要件に影響を与える可能性がある。

【0139】

サブネットごとのシステムの分散数は、コンピュータネットワークとグラフ分析の両方で一般的な「ロングテール」分布を示すために、３つの異なる軸セットを使用して図８Ａから８Ｃに示されている。図８Ａの線形プロットを参照すると、システム数の多いネットワークが少数あることが分かる。同じデータを図８Ｂにおいて対数目盛のついたｙ軸でプロットすると、半分以上のサブネットが１０個以下のシステムを有することが明らかとなり、図８Ｃにおける両対数プロットにより、１，０００個を超えるシステムを有するサブネットは約１０個しかないことが明らかとなる。

【0140】

図９は、組織イントラネット内の様々なシステムのサブネットの数に対する送信元及び宛先アドレス数の散布図を両対数軸で示す。Ｍａｙｏネットワーク内のすべてのサブネットにわたる送信元及び宛先アドレス数の多様性を示すために、図９は、各「×」が１つのサブネットを表す散布図を示す。図９のｘ軸に沿った「×」の箇所はサブネット上のシステムの数を表し、図９のｙ軸に沿った箇所はこれらのシステムの個別の宛先アドレスの数を表す。垂直ｙ軸にあるサブネット（サブネットごとに１つのシステムを有する）は、サーバシステムである可能性がある。これらのシステムは、１つ又は複数の他のシステム（最大数千のシステム）とトラフィックを交換する。図９の「×」は、個別の送信元及び宛先アドレスの組み合わせの数が最も少ないサブネットの９０％が、より濃い色で表されるように分けられている。これらのサブネットは、７，０００個未満の送信元及び宛先の組み合わせを有する。したがって、そのようなサブネットにわたって送信元／宛先ベースでメトリックを評価するために実装され、そのようなメトリックを追跡するために使用される少なくとも７，０００個のカウンタのコピーを有するローカル監視デバイスを、Ｍａｙｏサブネットの約９０％を監視するために使用することができる。

【0141】

図１０及び図１１は、それぞれ、組織イントラネット内のウェブサーバについての送信元及び宛先アドレスの組み合わせの散布図を両対数軸で示したものと、組織イントラネット内のシステムのグループについての送信元及び宛先アドレスの組み合わせの散布図を両対数軸で示したものである。

【0142】

ほとんどのネットワークパケットには、送信元アドレスと宛先アドレスに加えて、送信元ポート番号と宛先ポート番号が含まれている。ポート番号は、建物の住所のアパート番号やスイート番号に類似すると考えることができる。番地（この例の宛先アドレスに類似）は、正しい建物（例えば、コンピュータシステム）へのデリバリーを保証でき、アパート番号（ポート番号に類似）は、メッセージが向けられているアパート（例えば、メッセージが向けられているアプリケーション）を指定することができる。６５，５３５個のユニークなポート番号の多くは、特定の目的のためにＩｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ（ＩＡＮＡ）に登録されている。例には、電子メール用の２５番ポート及びウェブトラフィック用の８０番ポートが含まれる。大きい番号のポートは通常、必要に応じてアプリケーションによって使用され、異なるトラフィックストリームは分離されたままとされる。例えば、複数のウィンドウを有するウェブブラウザは、各ウィンドウのデータを分離したままとするために個別のポートを使用できる。

【0143】

ポートの多様性は、ローカル監視デバイスの要件に影響を与える可能性がある。１つのウェブサーバのトラフィックについて、送信元ポート及び宛先ポートが図１０に示されている。図１０の各バブル（泡）は、送信元ポート及びアドレスポートのユニークな組み合わせを表し、バブルのサイズはそのポートの組み合わせでのトラフィックの量を示す。特定のアプリケーションとウェブサーバがサポートするプロトコルに関するいくつかの異なるトラフィックパターンが出現する。例えば、入ってくるウェブリクエストは通常、８０番ポートに到着し、これはグラフに注釈が付けられている。クライアントウェブブラウザによって選択されるそのトラフィックの送信元ポートの枠は、約１，０００から６５，０００である。さらに、暗号化されたウェブトラフィック（ＨＴＴＰＳ）は通常、４４３番ポートに到着し、Ｗｉｎｄｏｗｓ認証サーバとのトランザクションは３８９番ポートに到着し、ＳＱＬサーバとのコレスポンデンスは１４３３番ポートに到着する。送信元ポートと宛先ポートは多数あるが、この特定のサーバについて分析される振る舞いは約２０個しかない。

【0144】

この送信元ポートと宛先ポートの組み合わせが、記述及び測定可能な振る舞いパターンと見なされる場合、ネットワークの残りの部分にクエリを実行して、パターンの普及を判断することができる。例えば、ウェブサーバの８０番ポートについてクエリを実行すると、６，６９１個のシステムがその振る舞いを示していることがわかった。ウェブサーバ（暗号化あり／なし）、ＳＱＬクライアント及びＷｉｎｄｏｗｓ認証クライアントの４パターンを使用した場合、ウェブアプリケーションサーバとして振る舞う正確に５７個のシステムが特定された。

【0145】

単一のシステムに接続されたローカル監視デバイスは、これらのような高レベルパターンを利用して振る舞いを評価できることに留意されたい。中央監視システムは、ネットワーク上の多くのシステムからパターンコンポーネントを収集し、クラスター分析やその他の手法を適用して、個々のローカル監視デバイスからの観察を使用して共通の高次振る舞いモデルを導出することができる。振る舞いパターンが意味的に識別されない場合でも（例えば、パターンＡはウェブサーバに対応し、パターンＢはメールサーバに対応する）、パターンをネットワークから導出し、デバイスの特定の例の振る舞いを評価するときに使用することができる。

【0146】

同じ送信元／宛先ポートのプロットが、図１０のウェブサーバが存在するサブネットに対して生成され、図１１に示されている。図１１に示すポート分布は、プロットが生成されたサブネット上の４２３個のシステムにおそらく数百個のポートの組み合わせパターンがあることを示している。したがって、イントラネット全体の組み合わせ測定は非常に大規模である一方で、ローカル監視デバイスについての慎重に作成されたトラフィックモデルは、数百個又はおそらく数千個の独立したモデルを有する比較的大規模なサブネットをサポートすることができる。

【0147】

＜様々な特徴を備えたさらなる例＞
実装例は、次の番号付きの節において説明される。

【0148】

１．複数のローカル監視デバイスを備えた、分散ネットワーク監視のためのシステムであって、複数のローカル監視デバイスは、各々、少なくとも１つのコンピューティングデバイスとネットワークルータとの間に配置され、複数のローカル監視デバイスの各特定のローカル監視デバイスは、少なくとも１つのプロセッサを備え、少なくとも１つのプロセッサは、第１の期間にわたって、少なくとも１つのコンピューティングデバイスと特定のローカル監視デバイスに関連するネットワークルータとの間のネットワークトラフィックを受け取り、少なくとも１つのコンピューティングデバイスと特定のローカル監視デバイスに関連するネットワークルータとの間のネットワークトラフィックに基づいて、第１の期間にわたる正常なネットワークトラフィックのモデルを生成し、第１の期間に続く第２の期間にわたって、少なくとも１つのコンピューティングデバイスと特定のローカル監視デバイスに関連するネットワークルータとの間のネットワークトラフィックを受け取り、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータに基づいてメトリックを計算し、メトリックに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常か否かを判断し、第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、中央監視システムに、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を送るようにプログラムされており、中央監視システムは、少なくとも１つの第２のプロセッサを備え、少なくとも１つの第２のプロセッサは、複数のローカル監視デバイスの第１のローカル監視デバイスから、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を受け取り、第１のローカル監視デバイスから、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックに関する情報を受け取り、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックに関する情報に基づいて、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断し、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、第１のローカル監視デバイスに関連するネットワークの一部を介する通信を保護するためのアクションを起こすようにプログラムされている、分散ネットワーク監視のためのシステム。

【0149】

２．少なくとも１つのプロセッサは、正常なネットワークトラフィックのモデルに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であるか否かを判断するようにさらにプログラムされている、１．に記載のシステム。

【0150】

３．ネットワークトラフィックに関する情報は、第１のローカル監視デバイスによって生成される正常なネットワークトラフィックのモデルを備える、１．又は２．に記載のシステム。

【0151】

４．メトリックは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータのエントロピーを含む、１．から３．の何れか一項に記載のシステム。

【0152】

５．第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータは、送信元ＩＰアドレスを含む、請求項１．から４．の何れか一項に記載のシステム。

【0153】

６．第１の期間にわたる正常なネットワークトラフィックのモデルは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータの平均エントロピー値に基づく範囲を備える、１．から５．の何れか一項に記載のシステム。

【0154】

７．第１のローカル監視デバイスに関連するネットワークの一部を介する通信を保護するためのアクションは、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックが異常であったことを示すアラートをユーザに提示することを含む、１．から６．の何れか一項に記載のシステム。

【0155】

８．第１のローカル監視デバイスに関連するネットワークの一部を介する通信を保護するためのアクションは、第１のローカル監視デバイスに、第１のローカル監視デバイスが第２の期間にわたって受け取ったネットワークトラフィックを異常にした原因となる送信元ＩＰアドレスからのトラフィックをブロックさせることを含む、１．から７．の何れか一項に記載のシステム。

【0156】

９．少なくとも１つのプロセッサは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を備え、少なくとも１つのプロセッサは、少なくとも部分的にＦＰＧＡの論理ゲートの構成に基づいてプログラムされている、１．から８．のいずれか一項に記載のシステム。

【0157】

１０．少なくとも１つのプロセッサは、特定用途向け集積回路（ＡＳＩＣ）を備え、少なくとも１つのプロセッサは、少なくとも部分的にＡＳＩＣの論理ゲートの構成に基づいてプログラムされている、１．から９．の何れか一項に記載のシステム。

【0158】

１１．少なくとも１つのプロセッサを備えた分散ネットワーク監視のための装置であって、少なくとも１つのプロセッサは、第１の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取り、第１の期間にわたる正常なネットワークトラフィックのモデルを生成し、第１の期間に続く第２の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取り、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータに基づいてメトリックを計算し、メトリックに基づいて、正常なネットワークトラフィックのモデルを使用して、第２の期間にわたって受け取ったネットワークトラフィックが異常か否かを判断し、第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、中央監視システムに、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を送るようにプログラムされている、分散ネットワーク監視のための装置。

【0159】

１２．少なくとも１つのプロセッサは、第１の期間にわたる正常なネットワークトラフィックのモデルを中央監視システムに送るようにさらにプログラムされている、１１．に記載の装置。

【0160】

１３．第１のイーサネットポートと、第２のイーサネットポートと、をさらに備え、少なくとも１つのプロセッサは、第１のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも一部を受け取るようにさらにプログラムされている、１１．又は１２．に記載の装置。

【0161】

１４．少なくとも１つのプロセッサは、第２のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも一部を、少なくとも１つのコンピューティングデバイスに送るようにさらにプログラムされている、１３．に記載の装置。

【0162】

１５．少なくとも１つのプロセッサは、第２のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも第２の部分を受け取り、第１のイーサネットポートを使用して、第１の期間にわたって受け取ったネットワークトラフィックの少なくとも第２の部分をネットワークルータに送るように、さらにプログラムされている、１３．又は１４．に記載の装置。

【0163】

１６．メトリックは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータのエントロピーを含む、１１．から１５．の何れか一項に記載の装置。

【0164】

１７．第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータは、宛先ポートを含む、１１．から１６．の何れか一項に記載の装置。

【0165】

１８．第１の期間にわたる正常なネットワークトラフィックのモデルは、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータの平均エントロピー値に基づく範囲を備える、１１．から１７．の何れか一項に記載の装置。

【0166】

１９．少なくとも１つのプロセッサは、中央監視システムから、装置が第２の期間にわたって受け取ったネットワークトラフィックを異常にした原因となる送信元ＩＰアドレスからのトラフィックをブロックする命令を受け取るように、さらにプログラムされている、１１．から１８．の何れか一項に記載の装置。

【0167】

２０．少なくとも１つのプロセッサは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を備え、少なくとも１つのプロセッサは、少なくとも部分的にＦＰＧＡの論理ゲートの構成に基づいてプログラムされている、１１．から１９．の何れか一項に記載の装置。

【0168】

２１．第１の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取る工程と、第１の期間にわたる正常なネットワークトラフィックのモデルを生成する工程と、第１の期間に続く第２の期間にわたって、少なくとも１つのコンピューティングデバイスとネットワークルータとの間のネットワークトラフィックを受け取る工程と、第２の期間にわたって受け取ったネットワークトラフィックに関連するメタデータのパラメータに基づいて、メトリックを計算する工程と、メトリックに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常か否かを判断する工程と、第２の期間にわたって受け取ったネットワークトラフィックが異常であると判断されたことに応えて、中央監視システムに、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を送る工程と、を有する、分散ネットワーク監視のための方法。

【0169】

２２．第１の期間にわたる正常なネットワークトラフィックのモデルを中央監視システムに送る工程をさらに有する、２１．に記載の方法。

【0170】

２３．第２の期間にわたって受け取ったネットワークトラフィックが異常であることを示す情報を受け取る工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報を受け取る工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報に基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程と、第２の期間にわたって受け取ったネットワークトラフィックが異常であることが確認されたことに応えて、第２の期間にわたって受け取ったネットワークトラフィックに関連するネットワークの一部を介する通信を保護するためのアクションを起こす工程と、を有する、２１．又は２２．に記載の方法。

【0171】

２４．第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程が、第２の期間にわたってネットワークトラフィックを受け取ったローカル監視デバイスを含むローカル監視デバイスのクラスターを識別する工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報を、クラスター内の別のローカル監視デバイスに関連する正常なネットワークトラフィックの第２のモデルと比較する工程と、正常なネットワークトラフィックの第２のモデルと比較してメトリックが異常であることに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程と、を有する、２３．に記載の方法。

【0172】

２５．第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程が、第２の期間にわたってネットワークトラフィックを受け取ったローカル監視デバイスを含むローカル監視デバイスのクラスターを識別する工程と、第２の期間にわたって受け取ったネットワークトラフィックに関する情報を、ローカル監視デバイスのクラスターに関連する正常なネットワークトラフィックの第３のモデルと比較する工程であって、第３のモデルが、クラスター内の複数のローカル監視デバイスに関連する正常なネットワークトラフィックのモデルに基づいて生成されたものである、工程と、正常なネットワークトラフィックの第３のモデルと比較してメトリックが異常であることに基づいて、第２の期間にわたって受け取ったネットワークトラフィックが異常であることを確認する工程と、を有する、２３．に記載の方法。

【0173】

２６．２１．から２５．の何れか一項に記載の方法を実行するよう構成された少なくとも１つのハードウェアプロセッサを備えるシステム。

【0174】

２７．プロセッサによって実行された時にプロセッサに２１．から２５．の何れか一項に記載の方法を実行させるコンピュータ実行可能命令を含む非一時的コンピュータ可読媒体。

【0175】

いくつかの実施形態では、本明細書に記載の機能及び／又はプロセスを実行するための命令を格納するために任意の適切なコンピュータ可読媒体を使用することができる。例えば、いくつかの実施形態では、コンピュータ可読媒体は、一時的又は非一時的なものであってもよい。例えば、非一時的コンピュータ可読媒体は、磁気媒体（ハードディスク、フロッピーディスクなど）、光学媒体（コンパクトディスク、デジタルビデオディスク、ブルーレイ（登録商標）ディスクなど）、半導体媒体（ＲＡＭ、フラッシュメモリ、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）など）、非一過性の若しくは伝送中に永続性の外形を欠くことのない任意の適切な媒体、及び／又は任意の適切な有形媒体を含むことができる。別の例として、一時的コンピュータ可読媒体は、ネットワーク上の、有線での、導体での、光ファイバーでの、回路での信号、一過性で伝送中に永続性の外形を欠くその他の適切な媒体、及び／又は任意の適切な無形媒体を含むことができる。

【0176】

本明細書において使用されるように、メカニズムとの用語は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の適切な組み合わせを包含することができることに留意すべきである。

【0177】

図４から図６のプロセスの上記のステップは、図中に示され記載された順序及びシーケンスに限定されない任意の順序又はシーケンスで実行又は遂行できることは理解されるべきである。また、図４から図６のプロセスの上記のステップのいくつかは、待ち時間及び処理時間を短縮するために必要に応じて実質的に同時に又は並行して実行又は遂行することができる。

【0178】

本発明について、前述の例示的な実施形態において説明及び図示したが、本開示は例としてのみなされたものであり、本発明の実装の詳細における多数の変更を、特許請求の範囲によってのみ限定される本発明の精神及び範囲から逸脱することなく行うことができることが理解される。開示された実施形態の特徴は様々に組み合わせることができ再構成することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A-C】

【図9】

【図10】

【図11】

【国際調査報告】