▶ パロ アルト ネットワークス，インコーポレイテッドの特許一覧
特開2022-141671ＩｏＴセキュリティにおけるパターンマッチングベースの検出
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022141671
(43)【公開日】2022-09-29
(54)【発明の名称】ＩｏＴセキュリティにおけるパターンマッチングベースの検出
(51)【国際特許分類】
G06F 21/55 20130101AFI20220921BHJP
【ＦＩ】
G06F21/55 340
【審査請求】有
【請求項の数】30
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2022103183
(22)【出願日】2022-06-28
(62)【分割の表示】P 2020567602の分割
【原出願日】2019-06-18
(31)【優先権主張番号】62/686,544
(32)【優先日】2018-06-18
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】517392861
【氏名又は名称】パロ アルト ネットワークス，インコーポレイテッド
【氏名又は名称原語表記】Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．
【住所又は居所原語表記】３０００ Ｔａｎｎｅｒｙ Ｗａｙ，Ｓａｎｔａ Ｃｌａｒａ，Ｃａｌｉｆｏｒｎｉａ ９５０５４，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ドゥ，ジュン
(72)【発明者】
【氏名】ワン，メイ
(72)【発明者】
【氏名】エガラド，ヘクター ダニエル
(72)【発明者】
【氏名】シア，ジァンホン
(57)【要約】 （修正有）
【課題】モノのインターネット（ＩｏＴ）デバイスの望ましくない挙動を検出する方法及びシステムを提供する。
【解決手段】ＩｏＴデバイスの望ましくない挙動を検出する方法は、コンピュータシステムのＩｏＴデバイス・イベント検出エンジンが、第１ＩｏＴデバイス・イベントを検出するステップと、ＩｏＴデバイス・アクティビティ生成エンジンが、第１ＩｏＴデバイス・イベント及びその他のイベントからアクティビティデータ構造を生成するステップと、ＩｏＴデバイス・アクティビティ・パターンマッチングエンジンが、アクティビティデータ構造に基づいて、第１ＩｏＴデバイスのアクティビティを決定するステップと、ＩｏＴデバイス・アクティビティ・パターンマッチングエンジンが、第１ＩｏＴデバイスのプロファイルが帰属されるデバイスについて望ましくない挙動を示す場合に、アラートを生成するステップと、を含む。
【選択図】図２
【解決手段】ＩｏＴデバイスの望ましくない挙動を検出する方法は、コンピュータシステムのＩｏＴデバイス・イベント検出エンジンが、第１ＩｏＴデバイス・イベントを検出するステップと、ＩｏＴデバイス・アクティビティ生成エンジンが、第１ＩｏＴデバイス・イベント及びその他のイベントからアクティビティデータ構造を生成するステップと、ＩｏＴデバイス・アクティビティ・パターンマッチングエンジンが、アクティビティデータ構造に基づいて、第１ＩｏＴデバイスのアクティビティを決定するステップと、ＩｏＴデバイス・アクティビティ・パターンマッチングエンジンが、第１ＩｏＴデバイスのプロファイルが帰属されるデバイスについて望ましくない挙動を示す場合に、アラートを生成するステップと、を含む。
【選択図】図２
【特許請求の範囲】
【請求項1】
モノのインターネット（IoT）デバイスの望ましくない挙動を検出する方法であって、前記方法は、
コンピュータシステムのIoTデバイス・アクティビティ・パターンマッチングエンジンが、パターンのスーパーセットについてパターンの第１サブセットを、複数のIoTデバイス・プロファイルの第１IoTデバイス・プロファイルと関連付けるステップと、
前記コンピュータシステムのIoTデバイス・プロファイリングエンジンが、前記第１IoTデバイス・プロファイルを第１IoTデバイスへ帰属させるステップと、
コンピュータシステムのIoTデバイス・イベント検出エンジンが、第１IoTデバイス・イベントを検出するステップであり、前記第１IoTデバイス・イベントは前記第１IoTデバイスの1つ以上のネットワークセッションを含む、ステップと、
コンピュータシステムのIoTデバイス・アクティビティ生成エンジンが、前記第１IoTデバイス・イベントおよびその他のイベントからアクティビティデータ構造を生成するステップと、
前記IoTデバイス・アクティビティ・パターンマッチングエンジンが、前記アクティビティデータ構造に基づいて、前記第１IoTデバイスのアクティビティを決定するステップであり、前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つを抽象化することによる、ステップと、
前記IoTデバイス・アクティビティ・パターンマッチングエンジンが、パターンの前記第１サブセットを前記第１IoTデバイスのアクティビティに対して適用するステップと、
前記IoTデバイス・アクティビティ・パターンマッチングエンジンが、パターンの前記第１サブセットの前記第１IoTデバイスのアクティビティに対する適用が、前記第１IoTデバイスのプロファイルが帰属されるデバイスについて望ましくない挙動を示す場合に、アラートを生成するステップと、
を含む、方法。
コンピュータシステムのIoTデバイス・アクティビティ・パターンマッチングエンジンが、パターンのスーパーセットについてパターンの第１サブセットを、複数のIoTデバイス・プロファイルの第１IoTデバイス・プロファイルと関連付けるステップと、
前記コンピュータシステムのIoTデバイス・プロファイリングエンジンが、前記第１IoTデバイス・プロファイルを第１IoTデバイスへ帰属させるステップと、
コンピュータシステムのIoTデバイス・イベント検出エンジンが、第１IoTデバイス・イベントを検出するステップであり、前記第１IoTデバイス・イベントは前記第１IoTデバイスの1つ以上のネットワークセッションを含む、ステップと、
コンピュータシステムのIoTデバイス・アクティビティ生成エンジンが、前記第１IoTデバイス・イベントおよびその他のイベントからアクティビティデータ構造を生成するステップと、
前記IoTデバイス・アクティビティ・パターンマッチングエンジンが、前記アクティビティデータ構造に基づいて、前記第１IoTデバイスのアクティビティを決定するステップであり、前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つを抽象化することによる、ステップと、
前記IoTデバイス・アクティビティ・パターンマッチングエンジンが、パターンの前記第１サブセットを前記第１IoTデバイスのアクティビティに対して適用するステップと、
前記IoTデバイス・アクティビティ・パターンマッチングエンジンが、パターンの前記第１サブセットの前記第１IoTデバイスのアクティビティに対する適用が、前記第１IoTデバイスのプロファイルが帰属されるデバイスについて望ましくない挙動を示す場合に、アラートを生成するステップと、
を含む、方法。
【請求項2】
前記生成されたアクティビティデータは、イベントのラベル付けされた集合体を含む、
請求項１に記載の方法。
請求項１に記載の方法。
【請求項3】
前記その他のイベントの少なくとも１つは、非ネットワークイベントを含む、
請求項１に記載の方法。
請求項１に記載の方法。
【請求項4】
複数の離散イベントが、機械学習を使用して１つ以上の複合イベントを形成するために集約されている、
請求項１に記載の方法。
請求項１に記載の方法。
【請求項5】
前記１つ以上の複合イベントが、共通要因集約を使用して形成される、
請求項４に記載の方法。
請求項４に記載の方法。
【請求項6】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のデバイス・プロファイルを含む、
請求項５に記載の方法。
請求項５に記載の方法。
【請求項7】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のオペレーティングシステム・ベンダを含む、
請求項５に記載の方法。
請求項５に記載の方法。
【請求項8】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のオペレーティングシステム・バージョンを含む、
請求項５に記載の方法。
請求項５に記載の方法。
【請求項9】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のアプリケーションの使用を含む、
請求項５に記載の方法。
請求項５に記載の方法。
【請求項10】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通の特定なサブネットワークを介した通信を含む、
請求項５に記載の方法。
請求項５に記載の方法。
【請求項11】
前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つの抽象化は、複数のイベントを集約することを含む、
請求項１に記載の方法。
請求項１に記載の方法。
【請求項12】
前記第１IoTデバイス・イベントまたは前記その他のイベントのうちの少なくとも1つの抽象化は、少なくとも１つのイベントを濃縮することを含む、
請求項１に記載の方法。
請求項１に記載の方法。
【請求項13】
前記少なくとも１つのイベントを濃縮することは、データをイベントに関連付けることを含む、
請求項１２に記載の方法。
請求項１２に記載の方法。
【請求項14】
前記イベントに関連付けられた前記データが、別のイベントを含む、
請求項１３に記載の方法。
請求項１３に記載の方法。
【請求項15】
前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つを抽象化することは、少なくとも１つのイベントを変換することを含む、
請求項１に記載の方法。
請求項１に記載の方法。
【請求項16】
プロセッサを含むシステムであって、前記プロセッサは、
パターンのスーパーセットについてパターンの第１サブセットを、複数のIoTデバイス・プロファイルの第１IoTデバイス・プロファイルと関連付け、
前記第１IoTデバイス・プロファイルを第１IoTデバイスへ帰属させ、
第１IoTデバイス・イベントを検出し、前記第１IoTデバイス・イベントは前記第１IoTデバイスの１つ以上のネットワークセッションを含み、
前記第１IoTデバイス・イベントおよびその他のイベントからアクティビティデータ構造を生成し、前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つを抽象化することによるものを含み、
前記アクティビティデータ構造に基づいて、前記第１IoTデバイスのアクティビティを決定し、
パターンの前記第１サブセットを前記第１IoTデバイスのアクティビティに対して適用し、
パターンの前記第１サブセットの前記第１IoTデバイスのアクティビティに対する適用が、前記第１IoTデバイスのプロファイルが帰属されるデバイスについて望ましくない挙動を示す場合に、アラートを生成する、
ように構成されている、
システム。
パターンのスーパーセットについてパターンの第１サブセットを、複数のIoTデバイス・プロファイルの第１IoTデバイス・プロファイルと関連付け、
前記第１IoTデバイス・プロファイルを第１IoTデバイスへ帰属させ、
第１IoTデバイス・イベントを検出し、前記第１IoTデバイス・イベントは前記第１IoTデバイスの１つ以上のネットワークセッションを含み、
前記第１IoTデバイス・イベントおよびその他のイベントからアクティビティデータ構造を生成し、前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つを抽象化することによるものを含み、
前記アクティビティデータ構造に基づいて、前記第１IoTデバイスのアクティビティを決定し、
パターンの前記第１サブセットを前記第１IoTデバイスのアクティビティに対して適用し、
パターンの前記第１サブセットの前記第１IoTデバイスのアクティビティに対する適用が、前記第１IoTデバイスのプロファイルが帰属されるデバイスについて望ましくない挙動を示す場合に、アラートを生成する、
ように構成されている、
システム。
【請求項17】
前記生成されたアクティビティデータは、イベントのラベル付けされた集合体を含む、
請求項１６に記載のシステム。
請求項１６に記載のシステム。
【請求項18】
前記その他のイベントの少なくとも１つは、非ネットワークイベントを含む、
請求項１６に記載のシステム。
請求項１６に記載のシステム。
【請求項19】
複数の離散イベントが、機械学習を使用して１つ以上の複合イベントを形成するために集約されている、
請求項１６に記載のシステム。
請求項１６に記載のシステム。
【請求項20】
前記１つ以上の複合イベントが、共通要因集約を使用して形成される、
請求項１９に記載のシステム。
請求項１９に記載のシステム。
【請求項21】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のデバイス・プロファイルを含む、
請求項２０に記載のシステム。
請求項２０に記載のシステム。
【請求項22】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のオペレーティングシステム・ベンダを含む、
請求項２０に記載のシステム。
請求項２０に記載のシステム。
【請求項23】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のオペレーティングシステム・バージョンを含む、
請求項２０に記載のシステム。
請求項２０に記載のシステム。
【請求項24】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通のアプリケーションの使用を含む、
請求項２０に記載のシステム。
請求項２０に記載のシステム。
【請求項25】
前記共通要因集約において使用される共通要因は、複数のデバイスに共通の特定なサブネットワークを介した通信を含む、
請求項２０に記載のシステム。
請求項２０に記載のシステム。
【請求項26】
前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つの抽象化は、複数のイベントを集約することを含む、
請求項１６に記載のシステム。
請求項１６に記載のシステム。
【請求項27】
前記第１IoTデバイス・イベントまたは前記その他のイベントのうちの少なくとも1つの抽象化は、少なくとも１つのイベントを濃縮することを含む、
請求項１６に記載のシステム。
請求項１６に記載のシステム。
【請求項28】
前記少なくとも１つのイベントを濃縮することは、データをイベントに関連付けることを含む、
請求項２７に記載のシステム。
請求項２７に記載のシステム。
【請求項29】
前記イベントに関連付けられた前記データが、別のイベントを含む、
請求項２８に記載のシステム。
請求項２８に記載のシステム。
【請求項30】
前記第１IoTデバイス・イベントまたは前記その他のイベントのうち少なくとも１つを抽象化することは、少なくとも１つのイベントを変換することを含む、
請求項１６に記載のシステム。
請求項１６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、IoTセキュリティにおけるパターンマッチングベースの検出に関する。
【図面の簡単な説明】
【0002】
【発明を実施するための形態】
【0003】
図1は、モノのインターネット（IoT）セキュリティにおけるパターンマッチングベースの検出のためのシステムの一例に係るダイアグラム100を示している。ダイアグラム100は、コンピュータで読取り可能な媒体（CRM）102、CRM102に結合されたIoTデバイス104-1...104-n(まとめて「IoTデバイス104」)、CRM102に結合されたIoTデバイス・アクティビティ生成エンジン106、CRM102に結合されたネットワークアクティビティ・データストア108、CRM102に結合されたIoTデバイス・プロファイリングエンジン110、CRM102に結合されたIoTデバイス・プロファイリング・データストア112、CRM102に結合されたIoTデバイス・アクティビティ・パターンマッチングエンジン114、および、CRM102に結合されたアクティビティパターン・データストア116を含んでいる。
【0004】
この文書において説明されるCRM102および他のコンピュータで読取り可能な媒体は、種々の潜在的に適用可能な技術を表すように意図されている。例えば、CRM102は、ネットワークまたはネットワークの一部分を形成するために使用され得る。２つのコンポーネントが１つのデバイス上に共に配置されている場合に、CRM102は、バスまたは他のデータコンジット（data conduit）またはプレーン（plane）を含み得る。第１コンポーネントが１つのデバイス上に置かれ、かつ、第２コンポーネントが異なるデバイス上に置かれている場合に、CRM102は、無線または有線のバックエンド・ネットワークまたはLANを含み得る。CRM102はまた、該当する場合、WANまたは他のネットワークの関連部分を包含し得る。
【0005】
この文書において説明されるコンピュータで読取り可能な媒体は、法定の(例えば、合衆国においては、米国特許法第１01条（35U.S.C.101）に基づく)全ての媒体を含み、かつ、コンピュータで読取り可能な媒体を含むクレーム（claim）が有効であるために排除が必要である限りにおいて、本質的に法定でない全ての媒体を特定的に排除するように意図されている。既知の法定のコンピュータで読取り可能な媒体は、ハードウェア(例えば、レジスタ、ランダムアクセスメモリ（RAM）、不揮発性（NV）記憶装置、等)を含むが、ハードウェアに限定されても、また、されなくてもよい。
【0006】
この文書において説明されるデバイス、システム、および、コンピュータで読取り可能な媒体は、コンピュータシステム、または、コンピュータシステムの一部分、もしくは、複数のコンピュータシステムとして実装され得る。一般的に、コンピュータシステムは、プロセッサ、メモリ、不揮発性ストレージ、および、インターフェイスを含む。典型的なコンピュータシステムは、たいてい、少なくともプロセッサ、メモリ、および、メモリをプロセッサに結合するデバイス（例えば、バス）を含む。プロセッサは、例えば、マイクロプロセッサといった、汎用中央処理装置（CPU）、または、マイクロコントローラといった、専用プロセッサであり得る。
【0007】
メモリは、限定ではないが、例として、ランダムアクセスメモリ（RAM）を含み得る。ダイナミックRAM（DRAM）およびスタティックRAM（SRAM）といったものである。メモリは、ローカル、リモート、または、分散され得る。バスは、また、プロセッサを不揮発性ストレージに結合することもできる。不揮発性ストレージは、しばしば、磁気フロッピー（登録商標）またはハードディスク、光磁気ディスク、光ディスク、CD-ROM、EPROM、またはEEPROMといった、読出し専用メモリ（ROM）、磁気または光カード、もしくは、大量のデータのための別の形態の記憶装置である。このデータのうちいくらかは、コンピュータシステム上でのソフトウェア実行の最中に、ダイレクトメモリアクセスプロセスによって、メモリの中へ書き込まれる。不揮発性ストレージは、ローカル、リモート、または分散され得る。不揮発性ストレージは、メモリ内で利用可能な全ての適用可能なデータを用いてシステムが作成され得るので、任意的である。
【0008】
ソフトウェアは、典型的に、不揮発性ストレージに保管される。実際、大きなプログラムについては、プログラム全体をメモリに保管することすら不可能である。それにもかかわらず、ソフトウェアを実行するために、必要であれば、処理に適したコンピュータで読取り可能なロケーションに移動されること、そして、説明目的のために、その場所は、この文書ではメモリと称されること、が理解されるべきである。たとえソフトウェアが実行のためにメモリに移動された場合でも、プロセッサは、典型的には、ソフトウェアに関連する値を保管するためにハードウェアレジスタを使用し、そして、理想的には、実行を高速化するために役立つローカルキャッシュを使用する。ここにおいて使用されるように、ソフトウェアプログラムは、ソフトウェアプログラムが「コンピュータで読取り可能な記憶媒体に実装される」ものとして参照される場合には、適用可能な既知または便利なロケーションに(不揮発性ストレージからハードウェアレジスタへ)保管されるものと仮定されている。プロセッサは、プログラムに関連する少なくとも１つの値がプロセッサによって読取り可能なレジスタに保管される場合には、「プログラムを実行するように構成されている」ものとみなされる。
【0009】
オペレーションの一例において、コンピュータシステムは、ディスクオペレーティングシステムといった、ファイル管理システムを含むソフトウェアプログラムである、オペレーティングシステムソフトウェアによって制御され得る。ファイル管理システムソフトウェアと関連するオペレーティングシステムソフトウェアの一例は、ワシントン州レドモンドのMicrosoft CorporationからのWindows(R)として知られるオペレーティングシステムのファミリー、および、それらが関連するファイル管理システムである。オペレーティングシステムソフトウェアとその関連ファイル管理システムソフトウェアの別の例は、Linux（登録商標）オペレーティングシステムおよびその関連ファイル管理システムである。ファイル管理システムは、典型的には、不揮発性ストレージに保管され、そして、プロセッサに、オペレーティングシステムによって必要とされる種々のオペレーションを実行させ、データを入出力し、かつ、不揮発性ストレージにファイルを保管することを含み、メモリにデータを保管する。
【0010】
バスは、また、プロセッサをインターフェイスに結合することもできる。インターフェイスは、１つ以上の入力及び／又は出力(I/O)デバイスを含み得る。実装特有または他の考慮に依存して、I/Oデバイスは、限定されるものではないが、例として、キーボード、マウス、または、他のポインティングデバイス、ディスクドライブ、プリンタ、スキャナ、および、表示装置を含む他のI/Oデバイスを含み得る。表示装置は、限定されるものではないが、例として、ブラウン管（CRT）、液晶ディスプレイ（LCD）、または、他の既知または便利な表示装置を含み得る。インターフェイスは、モデムまたはネットワークインターフェイスのうち１つ以上を含み得る。モデムまたはネットワークインターフェイスは、コンピュータシステムの一部分とみなすことができることが、正しく理解されるだろう。インターフェイスは、アナログモデム、ISDNモデム、ケーブルモデム、トークンリングインターフェイス、衛星伝送インターフェイス（例えば、「ダイレクトPC」）、または、コンピュータシステムを他のコンピュータシステムに結合するための他のインターフェイス、を含み得る。インターフェイスは、コンピュータシステムおよび他のデバイスがネットワーク内で一緒に結合されることを可能にする。
【0011】
コンピュータシステムは、クラウドベースのコンピューティングシステムの一部分として、または、介して、互換性があるか、もしくは、実装され得る。この文書において使用されるように、クラウドベースのコンピューティングシステムは、エンドユーザデバイスに対して仮想化コンピューティングリソース、ソフトウェア、及び／又は、情報を提供するシステムである。コンピューティングリソース、ソフトウェア、及び／又は、情報は、ネットワークといった、通信インターフェイスを介してエッジデバイスがアクセスすることができる、集中化されたサービスおよびリソースを維持することによって仮想化され得る。「クラウド（“cloud”）」は、マーケティング用語であってよく、そして、この文書の目的のために、ここにおいて記載されているネットワークのいずれかを含み得る。クラウドベースのコンピューティングシステムは、サービスへの加入を伴い、または、ユーティリティ・プライシング・モデルを使用することができる。ユーザは、エンドユーザ装置上に置かれているウェブブラウザまたは他のコンテナ（container）アプリケーションを通じて、クラウドベースのコンピューティングシステムのプロトコルにアクセスすることができる。
【0012】
コンピュータシステムは、エンジンとして、エンジンの一部分として、または、複数のエンジンを介して、実装され得る。この文書において使用されるように、エンジンは、１つ以上のプロセッサ、または、その一部分を含む。１つ以上のプロセッサの一部分は、１つ以上の任意の所与のプロセッサを含む、ハードウェアの全てより少ないハードウェアの一部分を含み得る。レジスタのサブセット、マルチスレッドプロセッサの１つ以上のスレッド専用のプロセッサの一部分、エンジンの機能の一部分を実行するためにプロセッサが全体的または部分的に専用である最中のタイムスライス、等といったものである。かくして、第１エンジンおよび第２エンジンは、１つ以上の専用プロセッサを有することができ、そして、第１エンジンおよび第２エンジンは、１つ以上のプロセッサを相互に、または、他のエンジンと共有することができる。実装特有または他の考慮に依存して、エンジンは、集中化され、または、その機能が分散され得る。エンジンは、ハードウェア、ファームウェア、または、プロセッサによる実行のためのコンピュータで読取り可能な媒体に具現化されたソフトウェアを含み得る。プロセッサは、この文書における図を参照して記述されるような、実装されたデータ構造および方法を使用してデータを新しいデータへと変換する。
【0013】
この文書で説明されるエンジン、または、この文書で説明されるシステムおよびデバイスが、それを通じて実装され得るエンジンは、クラウドベース（cloud-based）エンジンであり得る。この文書において使用されるように、クラウドベースエンジンは、クラウドベースコンピューティングシステムを使用してアプリケーション及び／又は機能性を実行できるエンジンである。アプリケーション及び／又は機能性の全部または一部分は、複数のコンピューティングデバイスにわたり分散することができ、そして、１つのコンピューティングデバイスだけに限定される必要はない。いくつかの実施形態において、クラウドベースのエンジンは、エンドユーザのコンピューティングデバイス上にローカルにインストールされた機能性及び／又はモジュールを有することなく、ウェブブラウザまたはコンテナアプリケーションを通じてエンドユーザがアクセスする機能性及び／又はモジュールを実行することができる。
【0014】
この文書において使用されるように、データストアは、テーブル、コンマで区切られた値(CSV)ファイル、従来のデータベース(例えば、SQL)、もしくは、他の適用可能な既知または便利な構成フォーマットを含む、任意の適用可能なデータ構成を有するリポジトリを含むように意図されている。データストアは、例えば、特定目的のマシンにおける物理的コンピュータで読取り可能な媒体、ファームウェア、ハードウェア、それらの組合せ、もしくは、適用可能な既知または便利なデバイスまたはシステムにおいて具現化されたソフトウェアとして、実装され得る。データベースインターフェイスといった、・データストア関連コンポーネントは、・データストアの「一部分（“part of”）」、他のシステムコンポーネントの一部分、または、それらの組合せとみなすことができる。ただし、・データストア関連コンポーネントの物理的なロケーションおよび他の特性は、この文書で説明される技術の理解にとって重大なものではない。
【0015】
データストアは、データ構造を含み得る。この文書において使用されるように、データ構造は、所与のコンテキスト内で効率的に使用され得るように、データをコンピュータに保管し、かつ、組織化する特定の方法と関連付けられている。データ構造は、一般的に、アドレス、それ自体がメモリに保管されてプログラムによって操作され得るビット列によって指定される、メモリ内の任意のロケーションでデータをフェッチ（fetch）し、かつ、保管するためのコンピュータの能力に基づいている。従って、いくつかのデータ構造は、算術演算を用いてデータアイテムのアドレスを計算することに基づいており、一方、他のデータ構造は、構造自体内にデータアイテムのアドレスを保管することに基づいている。多くのデータ構造は、両方の原理を用いており、ときどき、自明でない方法で組み合わされる。データ構造の実装は、たいてい、その構造のインスタンスを作成し、かつ、操作する一式のプロシージャを書くことを必要とする。この文書で説明されるデータストアは、クラウドベースのデータストアであり得る。クラウドベースのデータストアは、クラウドベースのコンピューティングシステムおよびエンジンと互換性のあるデータストアである。
【0016】
図1の例に戻ると、IoTデバイス104は、意図的に構築され、または、構成されたIoTデバイスを表すように意図されている。IoTデバイスの例は、サーモスタット、モバイルデバイス、生物学的マネージャ、知覚デバイス、および、機能性実行装置を含む。意図的に構築されたIoTデバイスにおいて、IoTデバイス104は、特定のオペレーションパラメータを有するように構築されている。例えば、温度計は、温度センサからの信号を供給するように構築され得る。意図的に構成されたIoTデバイスにおいて、IoTデバイス104は、人間（human）または人工エージェントからの入力のとおりに特定のオペレーションパラメータに従って動作するように構成され得る。例えば、IoTデバイス104のIoTデバイスは、設定可能な時間に部屋を設定可能な温度まで冷却するようにエアコンを制御するように構成されたサーモスタットであり得る。別の例として、エージェントは、IoTデバイスが特定のデータソースと通信すべきではないと指定することができ、そして、IoTデバイスは、意図的な構成の一部分として特定のデータソースと通信することを控えるように構成され得る。
【0017】
特定の実装において、IoTデバイス104は、有線または無線インターフェイスを含み、これを通じて、IoTデバイス104は、有線および無線接続にわたりデータを送信および受信することができる。この文書において使用されるように、用語「実装（“implementation”）」は、例示として説明のために役立ち、そして、必ずしも限定によるものではない実装を意味する。IoTデバイス104は、ネットワークを通じたデータの伝送において使用され得る固有の識別子を有し得る。IoTデバイス104の固有の識別子は、インターネットプロトコル・バージョン4(以降、「IPv4」として参照される)に従って作成された識別子、または、インターネットプロトコル・バージョン6(以降、「IPv6」として参照される)に従って作成された識別子を含むことができ、これら両方のプロトコルバージョンは、ここにおいて参照により組み込まれている。実装特有または他の考慮に依存して、IoTデバイス104は、適用可能な無線装置プロトコルに従ってデータを受信および送信するために適用可能な通信インターフェイスを含み得る。適用可能なワイヤレスデバイス・プロトコルの例は、Wi-Fi、ZigBee（R）、Bluetooth（登録商標）、および、他の適用可能な低消費電力通信規格を含む。
【0018】
特定の実装において、IoTデバイス104は、ステーション（station）として動作する。この文書において使用されるように、ステーションは、IEEE 802.11標準に準拠するワイヤレスメディアに対するメディアアクセス制御(MAC)アドレスおよび物理層(PHY)インターフェイスを有するデバイスとして参照され得る。従って、例えば、適用可能な場合に、ネットワーク装置はステーションとして参照され得る。IEEE 802.11a-1999、IEEE 802.11b-1999、IEEE 802.11g-2003、IEEE 802.11-2007、および、IEEE 802.11n TGn Draft 8.0(2009)が、参考により組み込まれている。この文書において使用されるように、802.11標準互換または802.11標準に準拠するシステムは、組み込まれている文書の要件及び／又は推奨事項、あるいは、書類の以前のドラフトからの要件及び／又は推奨事項の少なくとも１つ以上に準拠しており、そして、Wi-Fiシステムを含んでいる。Wi-Fiは、一般的にIEEE 802.11標準、並びに、Wi-Fi Protected Access(WPA)およびWPA2セキュリティ標準、そして、拡張認証プロトコル(EAP)標準と相関する非技術的な記述である。代替的な実施形態において、ステーションは、Wi-FiまたはIEEE 802.11とは異なる標準に準拠してよく、「ステーション」以外の何かとして参照されてよく、そして、無線または他のメディアに対する異なるインターフェイスを有し得る。
【0019】
特定の実装において、IoTデバイス104は、IEEE 802.3に準拠してネットワークサービスにアクセスするように構成されている。IEEE 802.3は、ワーキンググループであり、そして、有線イーサネットの物理層およびデータリンク層のMACを定義するワーキンググループによって作成されたIEEE標準の集合体である。これは、一般的に、いくつかの広域ネットワークアプリケーションを伴うローカルエリアネットワーク技術である。物理的な接続が、典型的には、種々のタイプの銅線またはファイバケーブルによって、ノード及び／又はインフラ装置(ハブ、スイッチ、ルータ)間で行われている。IEEE 802.3は、IEEE 802.1ネットワークアーキテクチャをサポートする技術である。関連技術においてよく知られているように、IEEE 802.11は、2.4、3.6、および5GHz周波数帯において無線ローカルエリアネットワーク（WLAN）コンピュータ通信を実装するための標準のワーキンググループおよび集合体である。標準IEEE 802.11-2007の基本バージョンには、その後の修正がある。これらの標準は、Wi-Fiブランドを使用したワイヤレスネットワーク製品の基礎を提供する。IEEE 802.1および802.3は、参照により組み込まれている。
【0020】
特定の実装において、IoTデバイス104は、それぞれのパーソナリティを有している。この文書において使用されるように、パーソナリティは、挙動（behavior）の集合体であり、挙動は、特定のタイプのデバイスを記述するために使用される。この文書において使用されるように、挙動は、一つ以上の関連するアクティビティのアプリケーション主導の集合体である。パーソナリティは悪いことがあり、つまり、パーソナリティは、後に望ましくない挙動を示すか、または、許容できないリスクを有するデバイスに属するものとして識別可能であることを意味する。パーソナリティは、良いことがあり、つまり、パーソナリティは、後に望ましくない挙動を示すことがなく、かつ、期待されないデバイスに属するものとして識別可能であることを意味する。デバイスは異常な（anomalous）挙動を示すことがあり、かつ、異常検出はデバイスが望ましくない挙動を示すか否かを判断するための有用なツールであり、そうして、異常な挙動は、ときどき、望ましくない挙動と関連付けられる。しかしながら、経時的に、異常な挙動は、まだ同定されていないが（as-of-yet-unidentified）、潜在的に良いパーソナリティを示すことがある。第１パーソナリティを有するデバイスが異常な挙動を示す場合に、所定の挙動が異常ではなければ、いくつかの点で第１パーソナリティと類似している第２パーソナリティを定義することが可能であろう。同様に、第１パーソナリティは、経時的に、以前は異常な挙動であったものを異常でない挙動として含むように、より良く定義され得るだろう。従って、IoTデバイスを種々のパーソナリティを有するものとして分類することができるシステムを提供するだけでなく、パーソナリティが柔軟な定義を有することができ、かつ、経時的に、新しいパーソナリティを定義することもできるシステムを提供することが望ましい。
【0021】
IoTデバイス・アクティビティ生成エンジン106は、IoTデバイス・関連イベントを使用してIoTデバイス・アクティビティデータ構造を生成するシステムを表すように意図されている。特定の実装において、IoTデバイス・アクティビティ生成エンジン106は、IoTデバイス104と同じLAN上にある。例えば、IoTデバイス・アクティビティ生成エンジン106は、IoTデバイス104のホーム（home）、及び／又は、LANを通じてネットワークサービスへのアクセスをIoTデバイス104に提供するように構成されたローカルデバイスにおいて、LANの一部分を形成するローカルデバイスとして実装され得る。代わりに、または、それに加えて、IoTデバイス・アクティビティ生成エンジン106、または、その一部分は、プライベートクラウドの一部分として実装され得る。IoTデバイス・アクティビティ生成エンジン106、または、その少なくとも一部分を実装するプライベートクラウドは、エンティティに特有であり得る。
【0022】
特定の実装において、IoTデバイス・アクティビティ生成エンジン106は、IoTデバイス104に関してローカルであるイベントを使用してアクティビティを生成するように機能する。IoTデバイスに関してローカルであるイベントを使用したアクティビティ生成において、IoTデバイス・アクティビティ生成エンジン106は、IoTデバイスと関連した、または、IoTデバイスを通じて部分的に形成されたLANの中のデバイスで実装され得る。IoTデバイス・アクティビティ生成エンジン106は、IoTデバイスの挙動がIoTデバイスのプロファイルに適しているか否かを判断することにおいて後に使用するために、LANの中のデバイスに関連するイベントからアクティビティデータ構造を生成することができる。例えば、IoTデバイス・アクティビティ生成エンジン106は、ローカルエージェントで実装することができ、そして、IoTデバイスのプロファイルに関してIoTデバイスオペレーションにおける望ましくないオペレーションを特定することに使用するために、ローカルエージェントでイベントを決定することができる。
【0023】
イベントの重要なサブクラスは、ネットワークセッションイベント、または、「ネットワークイベント（“network event”）」である。いくつかの実装において、ネットワークイベントは、ネットワークイベントキャプチャがパケットまたはフレームであるため、「パケットベース（“packet-based”）」(または「フレームベース（“frame-based”）」)イベントとして適切に参照され得る。特定の実装において、個別のネットワークイベントは、ネットワークセッションである。代わりに、または、それに加えて、離散的なネットワークイベントは、チャンク（chunk）へと分割された永続的なネットワークセッションの一部分であり、ここで、ネットワークセッションのチャンクは、全体として、ネットワークセッションを構成する。
【0024】
ネットワークアクティビティ・データストア108は、アクティビティデータ構造のデータストアを表すように意図されている。特定の実装において、ネットワークアクティビティの少なくともいくつかは、IoTデバイス104のうち１つに関連する変換されたイベントの表現を含む。この文書において使用されるように、アクティビティデータ構造は、ラベル付けされたイベントの集合体である。アクティビティデータ構造は、ローカルデータベース・アクセスイベント、有効なクエリーを介してログメッセージから獲得されたイベント、等といった、ネットワークイベントではないイベントの表現を含み得る。有利なことに、より詳細に後で説明される、パターンマッチングは、ネットワークイベントおよび非ネットワークイベントの両方を含むアクティビティデータ構造を有するアクティビティにおいて使用され得る。
【0025】
オペレーションの例において、IoTデバイス・アクティビティ生成エンジン106は、ネットワークアクティビティ・データストア108において、作成、読出し、更新、または削除（CRUD）を実行する。イベント変換は、例えば、図3を参照して、といったように、後でより詳細に説明される。
【0026】
IoTデバイス104のIoTデバイスに係るネットワークセッションは、ネットワークイベントであるため（または、ネットワークセッションが、一連のネットワークイベントの中へ「チャンク（“chunked”）」され得るため）、IoTデバイスは、ネットワークイベントの表現を含むネットワークアクティビティ・データストア108内のアクティビティ・データストラクチャによって定義されるアクティビティの参加者として識別され得る。IoTデバイスがプロファイルを与えられる実装において、パターンマッチングは、アクティビティパターンを最も適切であるとして特定されたものに限定するために、IoTデバイスのプロファイルを考慮に入れることができる。例えば、アクティビティパターンは、ウィンドウ上で実行している医療装置について生成することができ、これは、バイナリウィンドウダウンロード、リモートRPC接続、等といったアクティビティを、パターンマッチングの目的に最も適切なものにする。別の例として、パターンは、医療用画像装置とは異なる、セキュリティ装置のためにクラウドに画像を送信するといった、アプリケーションと関連付けるされ得る。ストリーミング、ファイルアップロード、管理、等といった、種々のアクティビティは、異なるプロファイルについて異なっている。膨大な数の可能性のせいで、この文書において説明される目標のいくつかを、妥当な精度で、IoTデバイスをプロファイリングする（profiling）ことなく達成することは、事実上不可能である。プロファイリングは、アクティビティに係るアクティビティ・パターンマッチングのために、より選択的な計算リソースの適用を可能にする(これは、マルウェアを検出する目的でパターンマッチングを実行する場合に限定的な成功を伴って使用されるような、単純な特徴のマッチングよりも、それ自身はるかに困難である)。
【0027】
IoTデバイス・プロファイリングエンジン110は、IoTデバイス104のプロファイリング、または、プロファイリングを促進するためのエンジンを表すように意図されている。IoTデバイスは、サーモスタット、X線装置、モーションセンサ、または、何らかの他のタイプのデバイスとしてプロファイリングすることができる。プロファイリングは、IoTデバイスの展開に先立って行うことができる。例えば、適用可能なLAN内にモーションセンサIoTデバイスが展開されていなくても、モーションセンサプロファイルは、IoTデバイス・プロファイル・データストア112内に存在し得る。IoTデバイス・プロファイリングエンジン110は、IoTデバイスの展開に先立って、人間または人工エージェントによってプロファイリングを促進にすることができる。IoTデバイスをネットワーク管理者と登録することによる、といったものである。プロファイリングは、関連するIoTデバイスについての情報を含む、ローカルまたはリモートの・データストアから、プロファイル情報を取得することを含み得る。パブリックソース、サービスプロバイダ、または、他のパーティから、といったものである。プロファイリングは、また、IoTデバイス・プロファイルの特徴の手動エントリーも含み得る。
【0028】
いくつかのネットワークにおいては、新しいIoTデバイスの展開が比較的頻繁に起こり、正確な事前プロファイリングを困難にしている。従って、特定の実装において、IoTデバイス・プロファイリングエンジン110は、理想的には、IoTデバイス104のそれぞれがプロファイリングされることを確実にするために、未だプロファイリングされていない任意のIoTデバイス104に関連するデータを分析する。特定の実装において、プロファイリングされたIoTデバイス104のそれぞれは、固有のプロファイルを有している。代替的に、IoTデバイス104のサブセットは、複数の暫定的な（provisional）プロファイルを有することができ、そのいくつかは、IoTデバイス104のサブセットについて、もはや「暫定的」としては参照されないであろう、唯一無二の１つのプロファイルを取得するために、経時的に除去され得る。プロファイリングおよび暫定的なプロファイルの削除は、パターンマッチングが後述されるのとほぼ同じ方法で、イベントの分析によって達成され得るが、比較的に多数の暫定的なプロファイルから開始することは計算的に禁止であり得ることが留意されるべきである。従って、IoTデバイス・プロファイリングエンジン110は、いくらかのインテリジェンスを有する必要があり、もしくは、人間または人工エージェントのインテリジェンスに依存することを要し、IoTデバイス・プロファイリングエンジン110が、各IoTデバイスについて潜在的なプロファイルを狭めることを可能にしている。例えば、IoTデバイス・プロファイリングエンジン110は、IoTデバイス・MACアドレスから製造者を特定することができ、そして、特定された製造者に関連するデータストアを参照して、製造者が使用するデバイスのタイプを決定することができる。
【0029】
コンピュータリソースが利用可能であり、かつ、リソースを消費したいという要望が存在する場合には、ディープパケットインスペクション(DPI)といった、いくつかの計算コストがかかる技術が使用され得る。より費用効果の高い技術は、LAN上で許可されるIoTデバイス・プロファイルの数を制限し、かつ、IoTデバイスがより正確にプロファイリングされるといった時間まで、IoTデバイスが全て許可される暫定的なプロファイルを有すると仮定することである。IoTデバイス・プロファイリングエンジン110がIoTデバイスのプロファイルを作成するための時間を必要とする場合には、未知のIoTデバイス・隔離（quarantine）エンジン(図示なし)が、少なくとも一時的に、IoTデバイスのオペレーションを妨害し、一方で、IoTデバイス・プロファイリングエンジン110は、IoTデバイスのプロファイルを作成しようと試みる。
【0030】
オペレーションの例において、IoTデバイス・プロファイリングエンジン110は、暫定的なプロファイルを含んでも、含まなくてもよいプロファイルを、IoTデバイス・プロファイル・データストア112に保管する。特定の実装において、プロファイルは、IoTデバイス104の少なくとも１つの展開に先立って保管され、かつ、比較的スタティック（static）である。比較的スタティックによって意味されるのは、人間または人工エージェントが、IoTデバイス・プロファイル・データストア112を一定期間にわたり変更する必要があることである。これは、これまでのところ未だプロファイリングされていないIoTデバイスについてIoTデバイス機能のうち少なくとも一部分の態様に壊滅的な影響を与え、または、IoTデバイスが、最初にプロファイリングされることなく動作するのを許可する（後者は、未知のデバイスに「デフォルト」プロファイルを与えるものとして特徴付けられ得る）。例えば、所与の期間内に、IoTデバイス・プロファイリングエンジン110が、IoTデバイスをIoTデバイス・プロファイル・データストア112内のプロファイルに一致させるのに失敗した場合、ネットワーク管理者（administrator）は、これまでのところ未だプロファイリングされていない（または、「デフォルト」にプロファイリングされた）IoTデバイスのプロファイリングに関連して挙動を起こすようにネットワーク管理者を促すアラートを受信することができ、それは、新しいプロファイルをIoTデバイス・プロファイル・データストア112へ追加することを含み得る。IoTデバイス14は、IoTデバイス・プロファイル・データストア112内の適用可能なプロファイルに対してリンクされている。少なくとも概念的には、IoTデバイスとそのプロファイルとの関連付けは、IoTデバイス・プロファイル・データストア112の一部分であると想定されるが、そうした関連付けを定義する情報は、IoTデバイス・データストア内に含まれ得る（図示なし）。
【0031】
IoTデバイスは、IoTデバイスの特性、IoTデバイスのオペレーション特性、および、IoTデバイスがその中で動作する環境の特性のうち１つ、または、組合せに基づいて、プロファイルを形成するように一緒にグループ化され得る。例えば、プロファイルを形成するように、特定の製造者の全てのサーモスタットIoTデバイスを一緒にグループ化されてよい。一般的に、IoTデバイス・プロファイリングエンジン110は、MACアドレス、（典型的には、ソースまたは宛先の）IPアドレス、パケットサイズ、UID、等といった、プロファイリングプロセスのために有用であるとして識別可能なデータなら何でも使用して、IoTデバイス104をプロファイリングする。実装特有または他の考慮に依存して、プロファイルは、グループにおけるIoTデバイスの正常なオペレーション挙動パターン、グループにおけるIoTデバイスの望ましくないオペレーション挙動パターン、または、その両方を含む。
【0032】
図1の例において、IoTデバイス・アクティビティ・パターンマッチングエンジン114は、ネットワークアクティビティ・データストア108に含まれる、IoTデバイス104のアクティビティが、IoTデバイス・プロファイル・データストア112に保管される際に、IoTデバイス104に対してそれぞれ帰属されるプロファイルに適切であるか否かを決定するためのシステムを表すように意図されている。第１プロファイルに関連するアクティビティパターン・データストア116内のパターンの第１サブセットに対する第１プロファイルを有するIoTデバイス104の第１サブセットのアクティビティ、第２プロファイルに関連するアクティビティパターン・データストア116内のパターンの第２サブセットに対する第２プロファイルを有するIoTデバイス104の第２サブセットのアクティビティ、等を、n次（nth）のサブセットおよびプロファイルにマッチングすることによるものである。IoTデバイスの機能を決定するために期待されるパターンを期待通りにマッチングすることは、期待されていないパターンをマッチングするのを失敗することに等しいが、用語「マッチング」は、この文書では、AがBに等しいか、または、AがBと等しくないかは、コンテキストで決定するものと理解して、一般的に使用されている。この文書において「一致しない（“does not match”）」または同等のものが使用されている限り、それは一般的に読みやすさを目的としており、前の文章で説明したのと同じ理解である。
【0033】
ダイアグラム100において、IoTデバイス・アクティビティ・パターンマッチングエンジン114は、IoTデバイス・予測挙動・パターンマッチング(サブ)エンジン118、IoTデバイス・異常挙動・パターンマッチング(サブ)エンジン120、アクティビティ識別(サブ)エンジン122、および、脅威検出(サブ)エンジン124を含んでいる。しかしながら、パターンのマッチングは、アグニスティックに（agnostically）に達成することができ、パターンマッチングの目的のために別個のエンジンを実装する必要を無くしていることに留意されたい。典型的な実装において、IoTデバイス・予測挙動・パターンマッチングエンジン118とIoTデバイス・異常挙動・パターンマッチングエンジン120とは、概念的に異なるだけである。望ましくない挙動は、望ましくないとして、制度上（institutional）またはセキュリティシステムによって、望ましくないとして定義される。良好なパーソナリティを有するIoTデバイスは異常な挙動を示すことがあり、かつ、それでも良好なパーソナリティを有するものと考えられるが、一方で、悪いパーソナリティを有するIoTデバイスが異常な挙動を示す必要はなく、かつ、それでも悪いパーソナリティを有するものと考えられることに留意されたい。望ましくない挙動を識別するために使用される技術は、例外的な（anomaly）検出を含み得るが、例外的な検出は望ましくない挙動検出の領域ではないので、このことは注目に値する。従って、特定の実施形態において、パターンマッチングは、正常挙動パターン、異常挙動パターン、または、両方に関連するパターンの適用を含む。この文書において使用されるように、パーソナリティは、数学的にモデル化された挙動パターンを含み、制度上の知識がパーソナリティモデルの中に構築されている。悪いパーソナリティの例は、３つの例を挙げると、ボット、C&Cセンタ(ボットネット)、または、マルウェアに乗っ取られたサーバに関連する挙動を含み、これらは全て認識可能な挙動を有し得るものである。
【0034】
特定の実装において、IoTデバイス・予測挙動・パターンマッチングエンジン118は、検出されたIoTデバイスの機能が、IoTデバイス・プロファイル・データストア112におけるIoTデバイスに起因するプロファイルについて許容可能なパラメータの範囲内にあるか否かを決定する目的のために、アクティビティパターン・データストア116からのパターンをネットワークアクティビティ・データストア108のアクティビティデータ構造に対して適用する。関係するプロファイルが１つより多い関連パターンを有する場合に、IoTデバイス・予測挙動・パターンマッチングエンジン118は、各パターンが適用されるまで、第２パターン等々をIoTデバイス・イベントに対して適用する。IoTデバイスの挙動が、IoTデバイスに起因し得るプロファイルのパターンそれぞれと一致しない場合に、IoTデバイス・予測挙動・パターンマッチングエンジン118は、アラートを生成する。アラートは、実装特有または他の考慮事項に依存して変動し得る、異なる重み付け（weights）を有し得る。低い優先度のアラートは、(その時点において)良性（benign）とみなされる挙動に関連するアラートとして特徴付けられ得る。同様に、IoTデバイス・予測挙動・パターンマッチングエンジン118は、パターンからの偏差を許容可能なパラメータの範囲内として扱うことができ、そして、明示的なアラートを生成しない。高い優先度のアラートは、悪意があり、または、危険なものとみなされ、かつ、自動的な対策をトリガする挙動に関連するアラートとして特徴付けされ得る。
【0035】
特定の実装において、IoTデバイス・予測挙動・パターンマッチングエンジン118は、デフォルトまたは暫定的なプロファイルを用いてIoTデバイスをプロファイリングすることにおいて、IoTデバイス・プロファイリングエンジン110を支援する。例えば、IoTデバイス・予測挙動・パターンマッチングエンジン118は、適切な一致を見い出すまで、少なくとも部分的に、ネットワークアクティビティ・データストア108内のアクティビティデータ構造を使って、識別可能な挙動履歴を使用して、プロファイルの階層（hierarchy）を処理することができる。プロファイルの階層は、最も可能性の高い候補プロファイルが最初に仮定されるように編成され得る。
【0036】
特定の実装において、IoTデバイス・異常挙動・パターンマッチングエンジン120は、IoTデバイス機能が、IoTデバイスに起因するプロファイルについて許容可能なパラメータの範囲外にあるか否かを決定する目的のために、パターンをIoTデバイス・イベントに対して適用する。関係するプロファイルが複数の関連パターンを有する場合に、IoTデバイス・異常挙動・パターンマッチングエンジン120は、各パターンが適用されるまで、第２パターン等々をIoTデバイス挙動に対して適用する。IoTデバイスの挙動が、IoTデバイスに起因するプロファイルのパターンのいずれかと一致する場合に、IoTデバイス・異常挙動・パターンマッチングエンジン120は、アラートを生成する。説明目的のため、記録されたIoTデバイス挙動が異常挙動を示す場合に、異常挙動パターンはマッチングされる。先に指摘したように、アラートは、多くの要因に依存する可変の重み付けを有することができ、ポリシからの偏差の識別、または、悪意あるIoTデバイスに関連する挙動の識別は、一般的に、パターンの中へ未だ組み込まれていない許容可能なオペレーションを単に示し得る挙動よりも高い重み付けに値するものである。
【0037】
アクティビティ識別エンジン122は、アクティビティ生成エンジン106によって生成され、かつ／あるいは、ネットワークアクティビティ・データストア108に保管されたアクティビティを識別することができる。
【0038】
脅威検出エンジン124は、脅威を発見するために教師なし学習(クラスタリングベースのアルゴリズム、パーティションベースのアルゴリズム、ニューラルネットベースのアルゴリズム、等)を使用することができる。
【0039】
オペレーションの例において、IoTデバイス・アクティビティ・パターンマッチングエンジン114のエンジンは、ネットワークアクティビティ・データストア108内のアクティビティデータ構造を、アクティビティデータ構造に関連するIoTデバイスに起因するIoTプロファイル・データストア112内のプロファイルと関連するアクティビティパターン・データストア116におけるパターンのサブセットに対してだけマッチングする。一致する(または、等価的には、一致しない)パターンが存在する場合には、アラートが生成され、または、生成されなくてよい。一般的に、セキュリティリスクがより重大であれば、アラートが生成される可能性がより高くなる。
【0040】
図2は、IoTデバイスの挙動を、IoTデバイスに起因するプロファイルに関連するパターンのサブセットに対してマッチングする方法の一例に係るフローチャート200を示している。この文書において説明されるフローチャート200および他のフローチャートは、該当する場合には、順次に記録され、または、並列なシーケンスへと再構成され得るモジュールを有している。フローチャート200は、モジュール202で始まり、そこで、(パターンのスーパーセットに係る)パターンの第１サブセットが、複数のIoTデバイス・プロファイルのうち第１IoTデバイス・プロファイルと関連付けられる。有利なことに、パターンマッチングエンジンを所与のプロファイルに関連するパターンに制限することによって、必要とされる計算を、IoTデバイス・アクティビティに対するパターンマッチングを実際に有用にするレベルまで低減することが可能である。実に、IoTネットワークのサイズが増大し、かつ、IoTデバイスのタイプが桁違いに増すにつれて、調整することさえ可能である。
【0041】
フローチャート200は、モジュール204へ続き、そこで、第１IoTデバイス・プロファイルは、第１IoTデバイスに帰属される。単純なシナリオにおいて、第１IoTデバイス・プロファイルは、展開に先立ってネットワーク管理者によって、第１IoTデバイスに帰属され得る。しかしながら、IoTネットワークは、動的であってよく、IoTデバイスが配備された後でIoTデバイスをプロファイリングすることを望ましくしている。これは、デフォルトIoTデバイス・プロファイルに対してIoTデバイスの挙動をパターンマッチングすることを含むことができ、そして、これまでのところプロファイリングされていないIoTデバイスを(理想的に)迅速にプロファイリングするために、利用可能なデータを使用する。検出の直後、または、プロファイリングが試みられる猶予期間後のいずれかで、これまでのところプロファイリングされていない全てのIoTデバイスに対して隔離、または、そうでなければ対策を展開することが望ましいことがある。
【0042】
フローチャート200は、モジュール206へ続き、そこでは、第１IoTデバイスの１つ以上のネットワークセッションを含む、第１IoTデバイス・イベントが検出される。特定の実装において、イベントは、受動的モニタリングによって検出される。検出されたイベントのやや普通なタイプは、おそらく、第１IoTデバイスへの、または、第１IoTデバイスからのメッセージである。パケットヘッダ内の情報といった、比較的少ないリソースを特徴付けのために必要とする個別のイベントを検出することに焦点を当てることが望ましくあり得る。しかし、さらに多くのイベントデータを得るために、DPIといった、他のよりリソース集約的な技術が使用され得る。
【0043】
フローチャート200は、モジュール208へ続き、そこでは、第１IoTデバイス・イベントおよび他のイベントからアクティビティデータ構造が生成される。アクティビティデータ構造の生成の態様は、抽象化であり、これは、IoTデバイスに関連するアクティビティのより有用な特徴付けのために、イベントに関連するデータの損失を必然的に伴う。アクティビティは、ラベル付けされたイベントの集合体として定義することができる。値が証明されているので、そのようにラベル付けされる。抽象化は、集約（aggregation）、濃縮(enrichment)、変換（translation）といった、イベントを適格とする（qualify）技術を含み得る。集約されたイベントのやや普通な例は、第１IoTデバイスによって周期的に送信され、かつ、複合(集約)イベントとして扱われるハートビート・メッセージの集合体である。しかしながら、集約されたイベントは、はるかに複雑であり、そして、必ずしも第１IoTデバイスに関連付けられないであろうデータを組み込むことさえ可能であるが、第１IoTデバイスと、それ以外の関連のないイベントとの間の相関が特定されていることを決定するためである。特定の実装において、離散イベント（discrete events）は、機械学習を使用して複合イベントを形成するために集約される。共通要因集約（common factor aggregation）は、検出され、かつ、モデル化された挙動の両方に適用されるものとして共通要因(いくつか例を挙げると、同じプロファイルの全てのデバイス、Windowsを使用し、telnetを使用している、同じOS、特定のサブネットと通信する全てのデバイス)に焦点を当てることによって、種々の異なる機械学習およびディープラーニングアルゴリズムを適用するための方法である。例えば、セッションイベントが、一緒に集約され得る。別の例においては、ストリーミングイベントが、一緒に集約され得る。イベントは、第１IoTデバイスに関してローカルに集約され得る。例えば、イベントは、第１IoTデバイスを有するLANの一部分として実装されるデバイスによって集約イベントを形成するために集約され得る。ラベル付けされた集約イベントは、この文書において「アクティビティ（“activities”）」として参照され得るが、より一般的に、アクティビティは、１つ以上のイベントのラベル付けされた集合体であり、離散的または集約的であり得ることが、留意されるべきである。濃縮は、データ(潜在的に他のイベントを含んでいる)をイベントと関連付けることを含む。変換とは、生のイベントデータを、アクティビティの特徴付けについてより適切なフォーマットへと変換することを含む。
【0044】
フローチャート200は、モジュール210へ続き、そこでは、パターンの第１サブセットがアクティビティに対して適用される。アクティビティは、第１IoTデバイスのシグネチャ(の一部分)として働く。パターンは、第１プロファイルによって制限されている。例えば、Windows(R)上で実行されている医療機器のプロファイルのためのパターンは、バイナリウィンドウのダウンロードパターン、および、医療機器のパターンからのリモートRPC接続を含み得る。これは、セキュリティカメラのIoTデバイス・シグネチャに対する比較のためには必要がないであろうパターンであり、クラウドへ画像を送信することに関連するパターンの方がより適切であり得る。正規（regular）表現は、パターンを定義する方法であるが、他の方法も同様に使用することができ、そして、特定の実装においては、少なくとも１つのパターンが正規表現を使用して定義されることを拒否する。パターンは、物理レイヤアクティビティに対してマッピングすることができ、かつ、かくして、上位レイヤのイベント、アクティビティ(特には、イベントのラベル付き集合体として定義された場合)、および、挙動(特には、１つ以上の関連アクティビティのアプリケーション駆動型の集合体として定義された場合)よりも、挙動の階層的な表現において、低いものとして特徴付けされ得ることが留意されるべきである。特定の実装においては、しかしながら、パターンはアクティビティに対してマッピングされる。
【0045】
概念的に、パターンは、特徴及び／又は支配的なトレンド(例えば、防犯カメラについては、ストリーミングが支配的である)と共に、ストリーミング、ファイルアップロード、管理、等といった、プロファイルについて関連するアクティビティを検出することとして特徴付けされ得る。特定の実装において、アクティビティのユニバースは、比較的に小さなセットへと蒸留される(例えば、定義されたアクティビティは、ログイン、認証、更新要求、ダウンロード、インストール、等といった、100個以下の一般的に人間が読むことができる集約されたイベントに制限され得る)。特定の実施形態において、複数の軽量エンジンは、それぞれの複数のアクティビティ(例えば、ダウンロード)またはアクティビティの比較的共通のサブセット(例えば、Windows(R)ダウンロード)に焦点を当てる。第１IoTデバイスは、プロファイリングされており、かつ、パターンの第１サブセットは、全ての可能なパターンの管理可能なサブセットであるので、IoTデバイスのシグネチャを、ほぼリアルタイムで、既知の許容可能または許容不可能なシグネチャと比較することが可能になる。有利なことに、パターンの完全なライブラリを適用することはできないが、IoTデバイスは最初にプロファイリングされるので、精度を維持しながらより選択的であることが可能である。
【0046】
フローチャート200は、モジュール212へ続き、ここでは、パターンの第１サブセットのアクティビティに対する適用が望ましくない挙動を示す場合に、アラートが生成される。アクティビティを望ましいオペレーションへマッピングすることは、同様に、有利であり得るが、この文書において説明されている技術の期待される実装は、IoTネットワークセキュリティのためのものであり、望ましくない挙動が検出された場合のアラート生成をおそらく含むこと、に注意することは価値がある。望ましくない挙動は、悪いパーソナリティを有するIoTデバイスの異常な挙動および正常を含み得る。
【0047】
図3は、ミラーゲートウェイを含むIoTデバイス・アクティビティ生成システムの一例のダイアグラム300を示している。ダイアグラム300は、LAN302、IoTデバイス・ゲートウェイ304、WAN308、データコンジット310、ミラーデータコンジット312、IoTデバイス・イベント検出エンジン314、IoTデバイス・イベント・データストア316、IoTデバイス・イベントツーアクティビティ生成エンジン318、コンテキスト・データストア320、IoTデバイス・アクティビティ・データストア322、およびIoTデバイス・プロファイル・データストア324を含んでいる。
【0048】
LAN302は、比較的ローカルなIoTデバイス・(および、潜在的に他のデバイス)のネットワークを表すように意図されている。エンタープライズネットワーク（enterprise network）は、WANセグメントにわたり結合され、地理的に分散されたLANを含み得ることが留意されるべきである。分散エンタープライズネットワークにおいて、IoTデバイス・ゲートウェイ304と互換性のあるローカルゲートウェイは、一般的に、地理的に分散されたエンタープライズネットワークにおいて種々のLANを接続するためにはゲートウェイ機能性に係るいくらかの形態が依然として必要であるが、各LANにおいてローカルであってよく(ここにおいては明示的な要件は示されていないが、各LANは、ときどき、IEEE 802.11用語において基本サービスセット(BSS)として参照される)、または、例えば、VLANトンネリングを使用してローカライズされてよい(ここにおいては明示的な要件は示されていないが、接続されたLANは、ときどき、IEEE 802.11用語において拡張サービスセット(ESS)として参照される)。
【0049】
IoTデバイス・ゲートウェイ304は、LAN302とWAN306との間のゲートウェイを表すように意図されている。ダイアグラム300において、IoTデバイス・ゲートウェイ306は、ミラーポート306を含んでいる。特定の実装において、IoTデバイス・ゲートウェイ304は、いくつかのIoTデバイストラフィックと非IoTデバイストラフィックとの間を区別し、かつ、特には、ミラーリング時に非IoTデバイストラフィックの少なくともいくつかを除外して、全体のトラフィックの全てよりも少ないミラーリングを行うことができる。代わりに、または、それに加えて、実装される複数のゲートウェイが存在してよく、そのうち１つはIoTデバイス・ゲートウェイ304であり、そして、そのうち１つは非IoTデバイス・ゲートウェイ(図示なし)である。もちろん、IoTデバイストラフィックと非IoTデバイストラフィックとの間を区別しないアグニスティックなゲートウェイは、実装において分かり易い（straight-forward）ものであり、そうした実装は、IoTデバイス・特有のタスクを実行する際に、非IoTデバイストラフィックを考慮から完全に又は少なくとも省略するように、IoTデバイス・イベント検出エンジン314に任せるだろう。
【0050】
WAN308は、LAN302の運営に責任を負うエンタープライズ(または他のエンティティ)の制御外である少なくともいくつかのハードウェアを含む、インターネットを表すように意図されている。
【0051】
データコンジット310は、CRMを表すように意図されており、それを通じて、トラフィックが、LAN302からIoTデバイス・ゲートウェイ304を介してWAN308に結合された宛先へ、および、IoTデバイス・ゲートウェイ304を介してWAN308に結合されたソースからLAN302上のIoTデバイスへ送信される。
【0052】
ミラーデータコンジット312は、データコンジット310からのトラフィックの少なくとも一部分が、それを通じて複製される、CRMを表すように意図されている。IoTデバイス・ゲートウェイ304のミラーポート306は、データコンジット310上のトラフィックの少なくとも一部分をミラーリングし、そして、ミラーリングされた部分をミラーデータコンジット312を通じてIoTデバイス・イベント検出エンジン314へダイレクト（direct）する。
【0053】
IoTデバイス・イベント検出エンジン314は、LAN302上のIoTデバイスによって送信及び／又は受信されたメッセージを検出し、かつ、イベント（または、イベントの表現）をIoTデバイス・イベント・データストア316に保管するエンジンを表すように意図されている。特定の実装において、IoTデバイス・イベント検出エンジン314、または、その一部分は、IoTデバイス・ゲートウェイ304と同じ物理デバイスにおいて実装される。代わりに、または、それに加えて、IoTデバイス・イベント検出エンジン314、または、その一部分は、消費者によって直接的に購入され、かつ、ネットワーク間のコンジットとして機能している、インターネットサービスプロバイダによって提供され得る。
【0054】
特定の実装において、IoTデバイス・イベント検出エンジン314は、IoTデバイスによって(または、IoTデバイスに対して)送信されるメッセージに関連するネットワークイベントを検出するように機能する。例えば、IoTデバイス・イベント検出エンジン314は、IoTデバイスによって(または、IoTデバイスに対して)送信された１つまたは複数のデータパケットを検出することができ、それは、その後、IoTデバイスに関連してアクティビティデータ構造を生成するために使用され得る。これは、次に、IoTデバイスが、IoTデバイスの所与のプロファイルについて適切に動作しているか否かを判断するために使用される。
【0055】
特定の実装において、IoTデバイス・イベント検出エンジン314は、フレーム、パケット、セグメント、及び／又は、データグラムといった、プロトコルデータユニット（PDU）からイベントパラメータを生成し、一方で、PDUの保管を控えている。特定的に、IoTデバイス・イベント検出エンジン314は、実際のPDUを不揮発性ストレージにローカルに保管することなく、IoTデバイスに対して、または、IoTデバイスから送信されるPDUからイベントメタデータを生成することができる。(このことは、IoTデバイス・イベント316が、不揮発性ストレージとして事実上は実装されることを意味するように解釈されるべきではない)。
【0056】
IoTデバイス・イベント・データストア316は、検出されたイベント、または、検出されたイベントを表すデータに係るデータストアを表すように意図されている。特定の実装において、IoTデバイス・イベント・データストア316は、イベントバッファを含んでいる。イベントバッファは、一定期間保持されるイベントおよび機能（features）の集合体を含んでいる。イベントバッファは、IoTデバイスと関連したプロファイルについて特有であり得る。例えば、イベントバッファは、特定のデバイスタイプのIoTデバイスと関連付けされ得る。代わりに、または、それに加えて、イベントバッファは、デバイスセンサイベント、セッションイベント、アプリケーションイベント、ユーザイベント、プロトコルイベント、および、ステータスイベントのうち１つまたは組合せである、イベントについて特有であり得る。イベントが保管される方法は、許容可能または許容不可能なIoTデバイス挙動を決定する目的で、イベントに対して後で適用されるパターンの性質に依存するか、または、依存しなくてよい。特定の実装において、パターンは、シンボル(すなわち、物理層PDU)を含んでいる。代わりに、または、それに加えて、パターンは、フレーム、パケット、または、セグメント／データグラム、もしくは、それらのコンポーネント、に対してマッチ可能な要素を含み得る。いくつかの実施形態において、パターンは、また、セッション、プレゼンテーション、及び／又は、アプリケーション層プロトコル、もしくは、コンポーネントに対してもマッチされ得る。
【0057】
IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイス・アクティビティ・データストア322における保管のために、IoTデバイス・イベント・データストア316において表されるイベントからのアクティビティを識別するように機能するエンジンを表すように意図されている。特定の実装において、IoTデバイス・イベントツーアクティビティ生成エンジン318は、アクティビティの一部分として含まれる、デバイスセンサイベント、セッションイベント、アプリケーションイベント、ユーザイベント、プロトコルイベント、および、ステータスイベントのうち１つまたは組合せを決定する。デバイスセンサイベントは、物理層に係る物理層、または、オープンシステム相互接続(これ以降、「OSI」として参照されるもの)モデルに係るデータリンク層で発生するイベントを含み得る。例えば、デバイスセンサイベントは、特定のデータソースと通信するためにIoTデバイスによって使用される仮想LAN(これ以降、「VLAN」として参照されるもの)を含み得る。セッションイベントは、OSIモデルのネットワーク層またはトランスポート層のいずれかで発生するイベントを含み得る。例えば、セッションイベントは、ソースと通信するためにIoTデバイスによって使用される特定のネットワークタイプを含み得る。アプリケーションイベントは、OSIモデルのセッション層、プレゼンテーション層、および、アプリケーション層のうち１つまたは組合せで発生するイベントを含んでいる。例えば、アプリケーションイベントは、ネットワークサービスにアクセスすることにおいてIoTデバイス・で実行されるアプリケーションの識別を含み得る。デバイスイベントは、特定のデバイスで発生するイベントを含み得る。ユーザイベントは、IoTデバイスと相互作用している（interacting）特定のユーザに伴って発生するイベントを含み得る。例えば、ユーザイベントは、特定のユーザがIoTデバイスと相互作用する、特定のインスタンスを含み得る。ステータスイベントは、IoTデバイスが動作しているか否かに関連するイベントを含み得る。例えば、ステータスイベントは、IoTデバイスが所与のオペレーション効率範囲内で動作しているか否かを示すイベントを含み得る。
【0058】
特定の実装において、IoTデバイス・イベントツーアクティビティ生成エンジン318は、データパケットを分析することによって、アクティビティパラメータ(データまたはメタデータ)を識別する。例えば、データパケットを特定のアプリケーションと相関させ得る場合に、IoTデバイス・イベントツーアクティビティ生成エンジン318は、特定のアプリケーションのアクティビティパラメータがIoTデバイスと関連して実行されたことを識別することができる。IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイスに対して、または、IoTデバイスから送信されたデータパケットからのアクティビティパラメータを識別するために、パケットヘッダ分析を使用することができる。代わりに、または、これに加えて、IoTデバイス・イベントツーアクティビティ生成エンジン318は、データパケットからアクティビティパラメータを識別するために、ディープパケット検査を使用することができる。例えば、IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイスから送信されたデータパケットのペイロード（payload）を分析し、そして、それに続いて、データパケットからアクティビティパラメータを識別するために、ディープパケット検査を使用することができる。別の例として、IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイスによって(または、IoTデバイスに対して)送信される１つまたは複数のデータパケットを、IoTデバイス・上で実行されている特定のアプリケーションのアクティビティに対して相関させることができる。
【0059】
特定の実装において、IoTデバイス・イベントツーアクティビティ生成エンジン318は、プロファイルベースの集約を使用してイベントを適格とするように機能する。イベントは、X線装置としてプロファイリングされたIoTデバイスのためのX線画像を送信すること、といった、特定のプロファイルと関連付けされ得る。例えば、IoTデバイス・イベントツーアクティビティ生成エンジン318は、所与のプロファイルのIoTデバイスから送信されたデータパケットの受信者に基づいて、イベントを適格とすることができる。別の例として、IoTデバイスがリモートデバイスと毎晩データを交換する場合(離散イベント)、離散イベントは集約され得る。別の例として、IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイス・ID、もしくは、所与のプロファイルのIoTデバイスに対して、または、IoTデバイスからデータを送信するために使用されるポートに基づいて、イベントを集約することができる。別の例として、IoTデバイス・イベントツーアクティビティ生成エンジン318は、イベントが、デバイスセンサイベント、セッションイベント、アプリケーションイベント、ユーザイベント、プロトコルイベント、および、ステータスイベントのうち１つまたは組合せであるか否かに基づいてイベントを集約することができる。有利なことに、リモートで、アプリケーション毎、IP毎、または、他の要因に基づく適格性確認（qualification）は、詳細なレベル（granular level）であり得る。
【0060】
コンテキスト・データストア320は、IoTデバイス・イベント・データストア316において表されるIoTデバイス・イベントを定性的に評価することにおいて、IoTデバイス・イベントツーアクティビティ生成エンジン318を援助する、IoTネットワーク関連データのデータストアを表すように意図されている。
【0061】
IoTデバイス・アクティビティ・データストア322は、適格にされた(例えば、集約され、濃縮され、または、他の方法で適格化され、および、変換された)イベントから派生したアクティビティデータ構造、および、コンテキスト・データストア320に関して、IoTデバイス・イベントツーアクティビティ生成エンジン318による、IoTデバイス・イベント・データストア316からのイベントを表すデータ、に係るデータストアを表すように意図されている。この文書において使用されるように、アクティビティは、１つ以上のイベントのラベル付けされた集合体である。アクティビティが唯一のイベントだけを含む場合に、そのアクティビティは、分散イベントとして参照され得る。アクティビティが２つ以上のイベントを含む場合に、そのアクティビティは、複合イベントとして参照され得る。アクティビティは、定義上、イベントのラベル付けされた集合体であるため、集約イベントの全てがアクティビティであるのではなく、しかしながら、集約イベントが後にラベル付けされる場合に、アクティビティになり得ることが、留意され得る。
【0062】
IoTデバイス・プロファイル・データストア324は、LAN302におけるIoTデバイス、及び／又は、IoTデバイス・プロファイルについてプロファイルテンプレートのデータストアを表すように意図されている。この文書において使用されるように、LAN302上の各IoTデバイスは、IoTデバイス・プロファイル・データストア324内に現存するか、または、これまでのところ識別されていないプロファイルを有するものと推定されている。少なくとも概念的には、より正確なプロファイルが識別されていないIoTデバイスは、「デフォルト」プロファイル、暫定的なプロファイル、または「最善の推測（“best guess”）」プロファイルを有し得る。実際に、いくつかの、または、全てのIoTデバイス・プロファイルでさえ、「最善の推測」プロファイルとみなされ得る。なぜなら、IoTデバイスが、いくつかの時点で、最初にプロファイリングし、感染し、または、迷走した挙動を開始するようにトリッキー（tricky）であり得ないと仮定する理由は存在しないからである。IoTデバイス・イベントツーアクティビティ生成エンジン318は、イベントが関連付けられているIoTデバイスのプロファイルに依存して、イベントを異なるように取り扱う。具体的に、異なるデバイスプロファイルは、いくつか例を挙げると、異なる集約、デバイス履歴からの濃縮データの異なる優先順位付け、パケット数に関する最も有用な正規化、と関連付けされ得る。
【0063】
再び、IoTデバイス・イベントツーアクティビティ生成エンジン318を参照すると、特定の実装において、IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイス・イベント・データストア316内のイベントから分析特徴（analytics features）を生成するように機能する。分析特徴は、複合イベントを含む、１つ以上のタイムスタンプされたイベントの変換である。この文書において使用されるように、複合イベントは、複数のイベントパラメータを含むが、「イベント（“event”）」として参照される。これは、離散イベントまたは(１つ以上の離散イベントを含み得る)イベントパラメータの組合せを表すように意図された、より一般的な用語である。例えば、離散温度感知インスタンスに関連する温度計から送信される信号といった、離散イベントは、複合イベントを生成するように、信号の宛先のためのイベントパラメータ、信号送信の履歴、同様に分類されたIoTデバイスの送信、等と組み合わされ得る。特定の実装において、IoTデバイス・イベントツーアクティビティ生成エンジン318は、LAN302上のIoTデバイスに対して、または、IoTデバイスから送信されるメッセージを使用して、IoTデバイスの分析特徴を生成する。例えば、IoTデバイス・イベントツーアクティビティ生成エンジン318は、タイムスタンプされてIoTデバイスの分析特徴を作成するように、後で、タイムスタンプされ得るイベントを決定するために、IoTデバイスに対して送信されたメッセージを検査することができる。特定の実装において、IoTデバイス・イベントツーアクティビティ生成エンジン318は、データロールアップウィンドウ(または、時間ウィンドウ)の中で、IoTデバイスの分析特徴を生成する。例えば、IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイスの特徴を決定するために、１時間以内にIoTデバイスから送信された全てのメッセージを検査することができる。別の例として、IoTデバイス・イベントツーアクティビティ生成エンジン318は、第１IoTデバイスから送信されたパケットを２４時間にわたり検査し、そして、第１および第２IoTデバイスの特徴を抽出するために、第２IoTデバイスから送信されたパケットを５分間にわたり検査することができる。IoTデバイスの特徴を抽出するために、IoTデバイス・イベントツーアクティビティ生成エンジン318によって使用されるデータロールアップウィンドウは、IoTデバイスのプロファイルに依存して変動し得る。例えば、IoTデバイス・イベントツーアクティビティ生成エンジン318は、IoTデバイスが温度計であるか、または、X線装置であるかに応じて、オペレーション中のIoTデバイスの特徴を抽出するために使用されるデータロールアップウィンドウを変更することができる。
【0064】
図4は、ローカル化されたエージェントを含む、IoTデバイス・アクティビティ生成システムの一例に係るダイアグラム400を示している。ダイアグラム400は、LAN402、IoTデバイス404-1からIoTデバイス404-n(まとめて、IoTデバイス404)、IoTデバイス・イベント検出エンジン406、IoTデバイス・イベント・データストア408、IoTデバイス・イベントツーアクティビティ生成エンジン410、IoTデバイス・ゲートウェイ412、および、WAN414を含んでいる。ダイアグラム400に示されるコンポーネントは、図3の例において同じ名称によって説明されているコンポーネントの機能のいくつかを含み得る。
【0065】
説明目的のために、LAN402は、通常、LAN402「上にある（“on”）」とみなされるであろう装置とは異なるものとして示されている。IoTデバイス404は、LAN402「上にある」装置の一例として動作するように意図されている。LAN402およびIoTデバイス404は、IoT LANとして特徴付けされ得る。
【0066】
IoTデバイス・イベント検出エンジン406は、LAN402上に、またも、存在する１つ以上のエージェントを表すように意図されている。ローカルエージェントは、LAN402上の物理デバイスにおいて実装されたソフトウェアを含んでよい。特定の実装において、IoTデバイス・イベント検出エンジン406の少なくとも一部分は、１つ以上のIoTデバイス404、１つ以上の専用IoTデバイス・イベント検出デバイス、IoTデバイス・ゲートウェイ412、または、いくつかの他のデバイスにおける、１つ以上のローカルエージェントを通じて実装されており、インテリジェンスが分散され得る。ローカル結合は、LANインターフェイス(または、PANインターフェイスといった、より小さなネットワークインターフェイス)を介してローカルエージェントをIoTデバイス404に対して動作的に接続することを含む。分散エンタープライズネットワークにおいて、ローカルエージェントは、各LANにおいてローカルであり(各LANは、ときどき、IEEE 802.11用語で基本サービスセット(BSS)として参照され得るが、ここにおいて明示的な要求は示されていない)、または、例えば、LANトンネル(接続されたLANは、IEEE 802.11用語で拡張サービスセット(ESS)として参照され得るが、ここにおいて明示的な要求は示されていない)を使用してローカル化され得る。実装特有の、または、他の考慮に依存して、IoTデバイス・イベント検出エンジン406は、有線または無線通信チャネルを介して通信するための有線通信インターフェイスおよび無線通信インターフェイスを含み得る。
【0067】
代わりに、または、それに加えて、IoTデバイス・イベント検出エンジン406の少なくとも一部分は、IoTデバイス404に対してリモートに実装され得る。例えば、IoTデバイス・イベント検出エンジン406の少なくとも一部分は、クラウドベースのシステムにおいて実装され得る。この例において、IoTデバイス404に対してリモートに実装されたIoTデバイス・イベント検出エンジン406の部分は、仮想プライベートネットワーク(これ以降、「VPN」)トンネルを介して、IoTデバイス404に関連するデータを受信することができる。例えば、IoTデバイス・イベント検出エンジン406は、VPNトンネルを介してIoTデバイス404から送信されたアウトバウンド（outbound）ネットワークトラフィックを受信することができる。加えて、そこを通じてIoTデバイス・イベント検出エンジン406がデータを送信および受信することができるVPNトンネルは、専用のネットワーク装置を使用して維持され得る。例えば、IoTデバイス・イベント検出エンジン406は、IoTデバイス404と通信するための専用ルータを使用して、IoTデバイス404に関連するデータを受信することができる。
【0068】
オペレーションにおいて、IoTデバイス・イベント検出エンジン406は、IoTデバイス・イベント・データストア408内のIoTデバイス・イベントを、IoTデバイス・イベントツーアクティビティ生成エンジン410による使用のために保存する。特定の実装において、IoTデバイス・イベントツーアクティビティ生成エンジン410の少なくとも一部分は、１つ以上のIoTデバイス404、１つ以上の専用IoTデバイス・イベント検出デバイス、IoTデバイス・ゲートウェイ412、または、いくつかの他のデバイスにおける、１つ以上のローカルエージェントを介して実装されており、インテリジェンスが分散され得る。
【0069】
IoTデバイス・ゲートウェイ412は、IoTデバイス404からWAN414へのIoTデバイス・メッセージのサブセットのためのアウトレット、および、WAN414からIoTデバイス404宛てのIoTデバイス・メッセージのためのインレットを提供する。IoTデバイス・ゲートウェイ412は、 (例えば、非IoTデバイス・メッセージからの)追加データを取得し、かつ、提供しても、また、しなくてもよく、該当する場合に、追加データは、IoTデバイス・イベントツーアクティビティ生成エンジン410へ提供され得る。
【0070】
図5は、IoTデバイス・アクティビティ抽出システムの一例に係るダイアグラム500を示している。そうしたシステムは、IoTデバイス・アクティビティ生成システムの中へ組み込むことができる。例えば、図3のIoTデバイス・イベントツーアクティビティ生成エンジン318、図4のIoTデバイス・イベントツーアクティビティ生成エンジン410、または、より一般的には、図1のIoTデバイス・アクティビティ生成エンジン106を参照のこと。ダイアグラム500は、生データ・データストア502、ドメイン知識・データストア504、IoTデバイス・イベント適格性確認エンジン506、IoTデバイス・アクティビティクラス・データストア508、IoTデバイス・アクティビティ抽象化エンジン510、および、IoTデバイス・アクティビティインスタンス・データストア512を含んでいる。
【0071】
生データ・データストア502は、IoTデバイス・イベント、コンテキスト、IoTデバイス・プロファイル、等のデータストアを含む、この文書において前述した・データストアの集合体を表すように意図されている。例えば、コンテキストおよびIoTデバイス・プロファイルと、ドメイン知識との間には、いくらかのクロスオーバーが存在し得るが、図5の理解のために明確な区別は必要とされない。
【0072】
ドメイン知識・データストア504は、外部ソース、管理入力、機械学習結果、等から考案されてきたルールおよびテンプレートを表すように意図されている。ドメイン知識は、例えば、ドメイン知識・複合ログインイベント・テンプレートに準拠するために、ログイン関連イベントが他の期待されるログインイベントと集約され得るように、複合ログインイベントをテンプレート化することによって、イベントのより精巧な適格性確認を可能にする。
【0073】
IoTデバイス・イベント適格性確認エンジン506は、ドメイン知識・データストア504からのルール及び／又はテンプレートを使用して、生データ502からの、少なくとも１つのイベントを含む、生データ間の関連性を識別するエンジンを表すように意図されている。「適格性確認（“Qualification”）」は、生データの抽象化が改善された予測力を発揮するように、生データ、および、特には、イベントのあらゆる特徴付けを意味するように意図されている。かくして、適格性確認は、集約、濃縮、および転換を含み得る。(コンテキスト上または明示的のどちらかで、区別されない場合には、「定量化（“quantification”）」も、また、適用可能であり、かつ、適切な場合に、適格性確認の一部分とみなすべきであることが、留意されるべきである)。
【0074】
ダイアグラム500において、IoTデバイス・イベント適格性確認エンジン506は、IoTデバイス・イベント集約エンジン514、IoTデバイス・イベント濃縮エンジン516、および、IoTデバイス・イベント変換エンジン518を含んでいる。IoTデバイス・イベント集約エンジン514は、イベントを集約するエンジンを表すように意図されている。普通な例において、持続的なネットワークセッションは、複数のインターバル(イベント)へと分割され得る。それらは、持続的なネットワークセッションの各インターバルを構成する複合イベントを形成するように集約され得る。IoTデバイス・アクティビティ抽象化エンジン510は、復号イベントを単一のアクティビティデータ構造パラメータとして取り扱うことができる(復号イベントが、例えば、他のイベントとの集約を通して、さらにもっと抽象化されないものと仮定している)。特定の実装において、IoTデバイス・イベント集約エンジン514は、IoTデバイス・プロファイルタイプによって集約する。有利なことに、プロファイルタイプによる集約は、大量のデータを管理可能にすることができる。代わりに、または、これに加えて、IoTデバイス・イベント集約エンジン514は、ドメイン知識・データストア504内の集約ルールに従って、いくつかのオプションを挙げると、ソース、宛先、ユーザ、継続時間、時刻（time-of-day）、および、アプリケーションのうち１つ以上によってイベントを集約する。代わりに、または、これに加えて、IoTデバイス・イベント集約エンジン514は、複合イベントテンプレートのコンポーネントの特性に一致する離散イベントを集約するために、ドメイン知識・データストア504内の複合イベントテンプレートを使用する。
【0075】
IoTデバイス・濃縮エンジン516は、イベントにデータを付加するエンジンを表すように意図されている。例えば、IoTデバイス・濃縮エンジン516は、複合イベントを形成するためのソースとしてIoTデバイスを有するネットワークイベントに、IoTデバイス・履歴またはIoTデバイス・情報を付加することができる。IoTデバイス・アクティビティ抽象化エンジン510は、複合イベントを単一のアクティビティデータ構造パラメータとして取り扱うことができるが、例えば、より信頼性が高い。付加され得る他のデータは、例えば、いくつか例を挙げると、イベントが検出された時点のネットワーク状態、IoTデバイスに関連するアカウントのユーザ情報、および、アプリケーションまたはデバイスの機能に関連するエラッタ（errata）を含み得る。
【0076】
IoTデバイス・イベント変換エンジン518は、生データ・データストア502からのイベントおよびそれらの関連データを、アクティビティデータ構造に組み込むために適したフォーマットへと変換するエンジンを表すように意図されている。例えば、変換（translation）は、イベントのバイト数を4つのカテゴリ(例えば、0-100KB、100KB-10MB、10MB-1GB、および1GB以上)に分類することを含み得る。IoTデバイス・アクティビティ抽象化エンジン510は、有用であるよりも正確であると判断された、正確なバイト数を考慮することなく、同じカテゴリのイベントを同様に取り扱うことができる。他の変換は、例えば、いくつか例を挙げると、IPをURLへと変換すること、ユニバーサルスケールへのパケット数による正規化、および、MACアドレスの組織固有の識別子(OUI)を製造者へと変換すること、を含み得る。
【0077】
IoTデバイス・アクティビティクラス・データストア508は、１つ以上のアクティビティデータ構造テンプレートの・データストアを表すように意図されている。オブジェクト指向プログラミングのコンテキストにおいて、テンプレートは、アクティビティデータ構造インスタンス(例えば、オブジェクト)を作成するための拡張可能なプログラムコードテンプレートとして定義され得る。この文書において使用されるように、「クラス（“class”）」という用語は、オブジェクト指向アプローチが、明示的に示されて使用されているか、または、コンテキストが同じように示しているかのいずれかでなければ、より広義に少しは解釈されるように意図されている。
【0078】
IoTデバイス・アクティビティ抽象化エンジン510は、IoTデバイス・アクティビティクラス・データストア508からアクティビティデータ構造のインスタンスを作成するエンジンを表すように意図されており、IoTデバイス・イベント適格性確認エンジン506からの１つ以上の適格な複合イベントから抽象化された値を、インスタンス化されたアクティビティデータ構造のパラメータに適用し、かつ、IoTデバイス・アクティビティインスタンス・データストア512のための新しいIoTデバイス・アクティビティデータ構造インスタンスを作成する。特定の実装において、IoTデバイス・アクティビティ抽象化エンジン510は、また、抽象化プロセスの結果によってメリットがあるように、IoTデバイス・アクティビティインスタンス・データストア512を更新し、読出し、または、削除することもできる。
【0079】
有利なことに、データは、生データ(特定の実装において大量であると期待されるもの)からの抽象化(特定の実装において膨大な数であると期待されるもの)をインスタンス化するとき、必然的に「失われる（“lost”）」が、IoTデバイス・アクティビティ抽象化エンジン510は、図5の例において、IoTデバイス・アクティビティインスタンス512から生データ・データストア502へのポインタ矢印520によって表されるように、適用可能な生データに対するポインタを維持することができる。このようにして、IoTデバイス・アクティビティ抽象化エンジン510は、生データをポインタで置き換えるものとして特徴付けされ得る。代わりに、または、それに加えて、生データは、単純化された記述子を用いて、または、その他の適用可能な方法で置き換えられ得るだろう。
【0080】
図6は、IoTデバイス・アクティビティパターンマッチングシステムの一例に係るダイアグラム600を示している。ダイアグラム600は、IoTデバイス・アクティビティ予測エンジン602、IoTデバイス・アクティビティ予測エンジン602に結合されたIoTデバイス・アクティビティインスタンス・データストア604、IoTデバイス・アクティビティ予測エンジン602に結合されたプロファイル特有のアクティビティパターン・データストア606、IoTデバイス・アクティビティ予測エンジン602に結合された正常アクティビティ・データストア608、IoTデバイス・アクティビティ予測エンジン602に結合された疑惑アクティビティ・データストア610、正常アクティビティ・データストア608および疑惑アクティビティ・データストア610に結合されたシナリオベース検証エンジン612、ドメイン知識由来ルール・データストア614、検証されたアクティビティ・データストア616、疑惑アクティビティ・データストア610に結合された抽象化エンジン618、抽象化エンジン618に結合されたコンテキスト・データストア620、抽象化エンジン618に結合されたリスク抽象化・データストア622、検証されたアクティビティ・データストア616およびリスク抽象化・データストア622に結合された脆弱性検出エンジン624、コンテキスト・データストア620およびリスク抽象化・データストア622に結合された重要度決定フィルタリングエンジン626、および、重要度決定フィルタリングエンジン626に結合された生データ・データストア628、を含んでいる。
【0081】
IoTデバイス・アクティビティ予測エンジン602は、複数のアクティビティのために構築されたアクティビティモデルをとり、かつ、検出されたアクティビティを所与のIoTデバイス・プロファイルについて適用可能なアクティビティモデルに一致させるように試みるエンジンを表すように意図されている。有利なことに、IoTデバイス・アクティビティ予測エンジン602は、マルウェアを検出するためだけでなく、むしろ（もしくは、また）、アクティビティに関連するIoTデバイスのプロファイルに基づいて、正常アクティビティを検出するために、アクティビティをアクティビティパターンとマッチングさせることができ、シグネチャが正常な挙動とマッチングされ得る。特定の実装において、パターンは、イベントレベルとは対照的に、アクティビティレベルでマッチングされる。
【0082】
IoTデバイス・アクティビティインスタンス604は、検出されたアクティビティを定義するために、集約され、濃縮され、かつ／あるいは、他のイベントと相関されたネットワークイベントを含む複数のアクティビティデータ構造を表すように意図されている。特定の実装において、アクティビティデータ構造は、アクティビティクラスを含む言語を使用して形成され得るものであり、アクティビティデータフォーマットおよびプロシージャを定義している。そうした実装において、アクティビティデータ構造は、イベントの変換に応答してその属性を変更し、かつ、アクティビティを構成するイベントを表しているイベントクラスに係る一式のインスタンス(すなわち、イベントオブジェクト)を含むことができる、アクティビティクラスのインスタンス(すなわち、アクティビティオブジェクト)として特徴付けされ得る。
【0083】
プロファイル特有のアクティビティパターン・データストア606は、特定のプロファイルに対して適用可能なアクティビティパターン・データストアのサブセット(図示なし)を表すように意図されている。説明目的のために、プロファイル特有のアクティビティパターン・データストア606は、種々の異なるアクティビティのためのパターンを含むことが仮定されている。
【0084】
正常アクティビティ・データストア608は、(少なくとも一時的に)良性であるとみなされたアクティビティデータ構造のデータストアを表すように意図されている。IoTデバイス・アクティビティ予測エンジン602は、アクティビティが正常アクティビティ・データストア608内に置かれるか否かに関して決定的である(特定の実装においては、構成可能であるが)、信頼性閾値（confidence threshold）を含み得る。従って、正常アクティビティは、関連する信頼値を有し得る。正常アクティビティは、例えば、機械学習モデルを改善するために使用され得る。
【0085】
疑惑アクティビティ・データストア610は、潜在的に悪意あるもの、または、そうでなければ、望ましくないものとしてみなされたアクティビティデータ構造のデータストアを表すように意図されている。
【0086】
シナリオベース検証エンジン612は、追加データの観点で検討するときに、正常アクティビティデータ608内のアクティビティが実際に疑わしいか否かを考慮するエンジンを表すように意図されている。正常アクティビティ・データストア608内のアクティビティデータ構造が信頼値を有する実装において、信頼値は、経時的に調整可能であり、そして、信頼値が信頼閾値を超える場合に、関連のアクティビティデータ構造は、代わりに、疑惑アクティビティ・データストア610へ移される。
【0087】
ドメイン知識由来ルール・データストア614は、以前には良性として指定されたアクティビティデータ構造が疑わしいものとして指定されるべきか否かに関する判断について適用可能な規則を含むデータストアを表すように意図されている。例えば、分離して考慮される複数のアクティビティが良性な場合であるが、集約においては疑わしいものとして考慮されるときに、正常アクティビティ・データストア608における第１アクティビティデータ構造は、IoTデバイス・アクティビティ予測エンジン602によって第２アクティビティデータ構造が考慮される際に、信頼性が低下することがある。つまり、複数の「正常な」アクティビティが組み合されて考えると、疑わしい場合がある。これが、シナリオベース検証エンジン612が「シナリオベース（“scenario-based”）」として参照される理由である。具体的に、特定のシナリオの下では、良性アクティビティが疑惑アクティビティとして再び特徴付けされ得る。
【0088】
検証されたアクティビティ・データストア616は、シナリオベース検証エンジン612によって検証されたアクティビティデータ構造を含むデータストアを表すように意図されている。例示目的のために、そうしたデータ構造は、変化しない「検証された（“verified”）」状態を有することが仮定されているが、実際には、検証されたアクティビティは、経時的に変化する信頼閾値を有し、その結果、検証されたアクティビティデータ構造が、疑わしいまで格下げされ（または、正常に戻り）得ることが理解されるべきである。シナリオベース検証エンジン612がアクティビティの検証に失敗した場合、シナリオベース検証エンジン612は、前述のように、検証されたアクティビティ・データストア616の代わりに、疑惑アクティビティ・データストア610内の対応するアクティビティデータ構造を保管し得る。
【0089】
抽象化エンジン618は、１つ以上の関連アクティビティのアプリケーション駆動型（application-driven）集合体である、挙動へとアクティビティを抽象化するエンジンを表すように意図されている。代わりに、または、それに加えて、抽象化は、挙動の集合体である、パーソナリティ（personality）に対するものであり得る。挙動は、特定のタイプのIoTデバイスを説明するために使用されている。挙動は、アプリケーション駆動型である。なぜなら、抽象化エンジン618は、その上で実行されているアプリケーション(ダイアグラム600において抽象化エンジン618のコンテキスト・データストア620への結合によって表され、ここで、コンテキストはアプリケーション差別化データを含む)を認識しているからであり、それらは、いくつかオプションを挙げると、サービスの品質、選択的なアクセス、特別なカプセル化メカニズム、及び／又は、アプリケーション特有のルーティング、といった、適切なポリシに適応している。特定の実装において、アプリケーション認識は適切であり、適切なポリシが、ネットワークのスイッチング及び／又はルーティング構造（fabric）を介して配布され、それらは、適用可能なプロトコル(例えば、SDN)を使用して、関連する機器ポート、ネットワークレグ（network legs）上で起動される。代わりに、または、それに加えて、適切なポリシは、ネットワーク管理ツールを使用してネットワークデバイスを設定すること、または、適用可能なネットワークデバイスに個別にログインして、設定すること、によって実装される。このことは、どのアプリケーションが異なって取り扱われるか認識していないポリシとは対照的である。実装、コンフィギュレーション、および、プリファレンス特有の要因に応じて、アプリケーションの認識（awareness）は、TCPまたはUDPポート番号(例えば、一式のポリシで大量のトラフィックをキャプチャするhttpのためのTCPポート80)を使用することから、パケットのペイロードでDPIを使用すること(この場合、ウェブ（Web）アプリケーション、特定のユーザ、等の間の差別化が達成され得る)といった、比較的に細分化されたものから変動し得る。特定の実装において、イベントは、ネットワークセッションを組み込む。これは、全てではないが、いくらかはDPIを使用するが、状況を必要とする相対的な細分性（granularity）を伴う(例えば、アクティビティ検証目的について信頼性をより良く確認するためのアクティブテストとして)。
【0090】
コンテキスト・データストア620は、疑惑アクティビティ・データストア610において表現されないアクティビティ(または挙動、もしくはパーソナリティ)データ構造、疑惑アクティビティ・データストア610に保管するための疑惑アクティビティを識別するようにドメイン知識がシナリオベース検証エンジン612によって既に使用されてはいなかった範囲内でのドメイン知識を含み、かつ、そうでなければ、IoTデバイスのための挙動(またはパーソナリティ)データ構造へのアクティビティの抽象化を改善するデータのキャッチオール（catch-all）として機能する、データストアを表すように意図されている。
【0091】
リスク抽象化・データストア622は、抽象化エンジン618によって、その中に保管された挙動(またはパーソナリティ)データ構造のデータストアを表すように意図されている。
【0092】
脆弱性検出エンジン624は、IoTネットワークにおける脆弱性を識別するために、検証されたアクティビティ・データストア616からの検証されたアクティビティデータ構造、および、リスク抽象化・データストア622内の挙動データ構造を考慮するエンジンを表すように意図されている。特定の実装において、脆弱性検出は、機械学習のための挙動モデルを改善するために使用されている。代わりに、または、それに加えて、脆弱性検出エンジン624は、脆弱性の検出に応答して、検証されたアクティビティ・データストア616を変更する。脆弱性検出エンジン624は、脆弱性の検出に応答して、リスク抽象化・データストア622を変更しても、または、しなくてもよい(ただし、検証されたアクティビティ・データストア616を変更することは、影響がシステムを通じて進行するにつれて結果として変化を生じ得る)。
【0093】
重要度決定フィルタリングエンジン626は、コンテキスト化（contextualized）されたIoTネットワーク脆弱性レポートを生成するエンジンを表すように意図されている。重要度決定フィルタリングエンジン626は、コンテキスト・データストア620に結合されており、特定の実装においては、レポートプリファレンス（reporting preference）を含んでいる。レポートプリファレンスは、デフォルト閾値、カスタマイズ閾値、および、レポートからデータをフィルタリングするために使用されるコンテキスト由来の閾値、を含み得る。デフォルト閾値は、全く閾値を含まなくてよく、全ての挙動データ構造がレポートされ得るようにしており、もしくは、所定の挙動を他の挙動とは異なる重み付けを行う段階的な閾値を含み得る。カスタマイズ閾値は、レポートの中に組み込まれるべきリスクの量、及び／又は、生成されるレポートのタイプに関するネットワーク管理者のプリファレンスを組み込むことができる。コンテキスト由来の閾値は、コンテキストに基づいて調整される閾値を含み得る。例えば、多くの潜在的リスクが存在する場合には、低リスクのレポートがフィルタリングされてよい。
【0094】
生データ・データストア628は、以前の抽象化プロセスによって失われたデータを含むデータストアを表すように意図されている。ポインタ矢印630は、もっとも、抽象化を実行する任意の適用可能なエンジンについて同様の矢印を示すことができたが（混乱を避けるために示されていない）、抽象化エンジン618によって(かつ、おそらく脆弱性検出エンジン624によって)抽象化される生データに対するポインタの維持（maintenance）を表すように意図されている。特定の実装において、重要度決定フィルタリングエンジン626は、コンテキスト化されたIoTネットワークの脆弱性レポートにおいて、ポインタまたは簡略化された記述子（descriptor）といった、適用可能な生データアイテムロケーション識別子を使用して、事前の抽象化プロセスの最中にフィルタリングで除かれた生データに対する参照を含んでいる。有利なことに、この特定の実装においては、IoTデバイスの挙動(または、複数のIoTデバイスの挙動)に関してより正確さが望まれる場合には、ネットワーク管理者、もしくは、人間またはその人工エージェント、または、何らかの他者が、コンテキスト化されたIoTネットワーク脆弱性レポートを掘り下げることができる。
【0095】
図7は、IoTデバイス・プロファイリングシステムの一例に係るダイアグラム700を示している。ダイアグラム700は、IoTデバイス・パーソナリティ定義エンジン702、IoTデバイス・パーソナリティ定義エンジン702に結合されたIoTデバイス・アクティビティインスタンス・データストア704、IoTデバイス・パーソナリティ定義エンジン702に結合されたドメイン知識・データストア706、IoTデバイス・パーソナリティ定義エンジン702に結合されたIoTデバイス・プロファイル・データストア708、IoTデバイス・パーソナリティ定義エンジン702およびIoTデバイス・プロファイル・データストア708に結合されたオフラインモデリングエンジン710、IoTデバイス・パーソナリティ定義エンジン702およびIoTデバイス・プロファイル・データストア708に結合されたパーソナリティ分類エンジン712、パーソナリティ分類エンジン712に結合された判断生成エンジン714、IoTデバイス・プロファイル・データストア708および判断生成エンジン714に結合されたIoTデバイス・プロファイルエンジン716、そして、ドメイン知識・データストアおよび判断生成エンジン714に結合されたネットワーク管理エンジン718、を含んでいる。
【0096】
IoTデバイス・パーソナリティ定義エンジン702は、IoTデバイス・アクティビティインスタンス・データストア704からのIoTデバイスに関連するアクティビティ、および、ドメイン知識・データストア706からのドメイン知識を使用して、IoTデバイスのパーソナリティを定義するエンジンを表すように意図されている。特定の実装において、IoTデバイス・パーソナリティ定義エンジン702は、IoTデバイス・プロファイル・データストア708内でIoTデバイス・プロファイルデータ構造を作成、読出し、更新、及び／又は、削除すること（CRUDing）によって、IoTデバイスのプロファイリングを促進している。代わりに、または、それに加えて、IoTパーソナリティ定義エンジン702は、IoTデバイスの挙動を示す特徴値を定義することによって、集約、濃縮、及び／又は、変換されたイベント（アクティビティデータ構造）を使用して、IoTデバイスのパーソナリティを定義することができる。
【0097】
オフラインモデリングエンジン710は、IoTパーソナリティ定義エンジン702から提供される特徴値を使用して、IoTネットワークセキュリティにおいて使用するための挙動検出モデルを構築するエンジンを表すように意図されている。特定の実装において、オフラインモデリングエンジン710は、IoTデバイスの挙動を示す特徴値を使用して、コンテキストベースの望ましくない挙動検出モデルを構築する。代わりに、または、それに加えて、オフラインモデリングエンジン710は、フィーチャ値の挙動パターンを認識し、コンテキストベースの望ましくない挙動検出モデルを構築する。代わりに、または、それに加えて、オフラインモデリングエンジン710は、特徴値における挙動パターンを認識し、かつ、コンテキストベースの望ましくない挙動検出モデルを構築するために、適用可能な機械学習エンジンを使用することができる。例えば、オフラインモデリングエンジン710は、学習状態遷移ベースの学習(決定木ベースの分類、ニューラルネットワークベースの分類、または、他の適用可能な機械学習分類を含む)、および、ディープラーニングのいずれか又は両方を使用して、IoTデバイスの挙動パターンを識別することができる。特定の実装において、オフラインモデリングエンジン710は、IoTデバイス・プロファイル・データストア708に対してモデルを提供する。
【0098】
パーソナリティ分類エンジン712は、IoTパーソナリティ定義エンジン702から提供される特徴値に対して挙動検出モデルを適用するエンジンを表すように意図されている。特定の実装において、パーソナリティ分類エンジン712は、IoTパーソナリティ定義エンジン702によって識別されるIoTデバイスの特徴値に対して、(オフラインモデリングエンジン710からの)IoTデバイス・プロファイル・データストア708におけるコンテキストベースの望ましくない挙動検出モデルを適用する。そうした実装において、パーソナリティ分類エンジン712は、IoTデバイスの(IoTデバイス・アクティビティインスタンス704由来の)検出された挙動を、IoTデバイスのモデル化された挙動に対して比較する信号を生成することができる。
【0099】
判断生成エンジン714は、判断を生成するために、パーソナリティ分類エンジン712からの信号を使用するエンジンを表すように意図されている。
【0100】
IoTデバイス・プロファイリングエンジン716は、IoTデバイスについてパーソナリティプロファイルを識別するエンジンを表すように意図されている。IoTデバイス・プロファイリングエンジン716は、IoTデバイス・アクティビティインスタンス・データストア704内のアクティビティデータ構造に由来する実際の挙動、および、IoTデバイス・パーソナリティ定義エンジン702によって決定された特徴値に基づいて、IoTデバイスについて、IoTデバイス・プロファイルデータ708内にIoTデバイス・プロファイリングプロファイルが存在するか否かを検出することができる(概念的に、特徴値は、IoTデバイス・パーソナリティ定義エンジン702からパーソナリティ分類エンジン716に渡されると仮定されており、特徴値をIoTデバイス・プロファイリングエンジン716に渡すか、もしくは、挙動またはパーソナリティといった、他の抽象化を提供し得る)。特定の実装において、IoTデバイス・プロファイリングエンジン716は、パーソナリティデータセットを用いてIoTデバイス・プロファイルデータ708を更新し、その特徴値生成機能を改善するためにIoTパーソナリティ定義エンジン702が使用することができる。
【0101】
特定の実装において、判断生成エンジン714は、IoTデバイスが正常な挙動パターン(例えば、良性の挙動パターン)からどのように逸脱したかを示すアラートを生成し、それは、ネットワーク管理エンジン716に対して提供される。ネットワーク管理エンジン716は、挙動アラートに従ってドメイン知識・データストア706を更新するエンジンを表すように意図されている。特定の実装において、アラートは望ましくない挙動アラートである。
【0102】
前述のテキストおよび図において説明された技術は、代替的な実装を生成するために必要とされる状況に応じて、混合され、そして、マッチングされ得る。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【外国語明細書】