(57)【要約】IoTネットワークにおけるモノのインターネット(IoT)デバイスの異常行為を検出するための技術である。IoTデバイスのIoTイベントが、キャプチャされ、そして、IoTデバイスの周期的アクティビティを識別するために、分析される。IoTデバイスの周期的アクティビティは時間にわたり追跡され、そして、周期的アクティビティにおける変動がIoTネットワークに対する潜在的脅威を評価するために分析される。
2022502736.tif 000002
【特許請求の範囲】
【請求項１】
第１IoTデバイスおよび第１IoTアプリケーションに関連するIoTイベントをキャプチャするステップと、
前記IoTイベントからIoTシグナル特徴を生成するステップであり、少なくともいくつかの前記IoTシグナル特徴は前記第１IoTデバイスおよび前記第１IoTアプリケーションのアクティビティに関連している、ステップと、
前記IoTイベントからバックグラウンド・イベント・コンテキストを抽出するステップと、
前記IoT信号特徴および前記バックグラウンド・イベント・コンテキストに基づいて、周期的アクティビティ・インスタンス記述子を生成するステップと、
非アクティブIoTイベントから外部コンテキストを抽出するステップと、
前記周期的アクティビティ・インスタンス記述子および前記外部コンテキストに基づいて、前記第１IoTデバイスの周期的アクティビティを識別するステップと、
前記第１IoTデバイスの前記周期的アクティビティの期待される周期性を決定するステップと、
前記第１IoTデバイスのアクティビティを検出するステップと、
前記第１IoTデバイスの検出された前記アクティビティを前記期待される周期性と一致させるステップと、
を含む、方法。
【請求項２】
前記方法は、さらに、
前記第１IoTデバイスの検出されたアクティビティの周期性が、期待される周期性と一致しない場合に、アラートを生成するステップ、
を含む、請求項１に記載の方法。
【請求項３】
前記方法は、さらに、
前記第１IoTデバイスの検出されたアクティビティの周期性が、悪意あるものとして知られている周期的なアクティビティの期待される周期性と一致する場合に、アラートを生成するステップ、
を含む、請求項１に記載の方法。
【請求項４】
前記方法は、さらに、
前記第１IoTデバイスの周期的アクティビティをモニタリングするステップと、
前記第１IoTデバイスの期待される周期的アクティビティが発生しない場合に、アラートを生成するステップと、
を含む、請求項１に記載の方法。
【請求項５】
前記方法は、さらに、
前記第１IoTデバイスの周期的アクティビティをモニタリングするステップと、
前記第１IoTデバイスの周期的アクティビティの周期性が、期待される周期性から逸脱した場合に、アラートを生成するステップと、
を含む、請求項１に記載の方法。
【請求項６】
前記期待される周期性は、フーリエ変換アルゴリズム、pスコアベースのアルゴリズム、または、指数分布アルゴリズムを使用して決定される、
請求項１に記載の方法。
【請求項７】
前記期待される周期性は、時系列相関を用いて決定される、
請求項１に記載の方法。
【請求項８】
前記周期的アクティビティ・インスタンス記述子は、正規化技術を使用して生成される、
請求項１に記載の方法。
【請求項９】
前記周期的アクティビティ・インスタンス記述子は、開始時間、終了時間、インターバル値、および、インターバル変動値を使用して、前記第１IoTデバイスのアクティビティを記述するデータ構造である、
請求項１に記載の方法。
【請求項１０】
前記周期的アクティビティ・インスタンス記述子は、
アクティビティID、周期的アクティビティID、多次元の統合された特徴値、特徴値範囲、デバイスID、アプリケーションID、ユーザID、サンプリングインターバル、特徴クラス、特徴グループ、特徴プライオリティ、アクティビティを分類するために使用されるアルゴリズム、タイムスタンプ、インターバル値、およびインターバル変動値、
のうち１つ以上を含む、
請求項１に記載の方法。
【請求項１１】
第１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デバイスの期待される周期的アクティビティが発生しない場合に、アラートを生成する、
ように構成されている、請求項１１に記載のシステム。
【請求項１５】
前記異常周期的アクティビティ・IoTネットワーク・脅威評価エンジンは、さらに、
前記第１IoTデバイスの周期的アクティビティをモニタリングし、
前記第１IoTデバイスの周期的アクティビティの周期性が、期待される周期性から逸脱した場合に、アラートを生成する、
ように構成されている、請求項１１に記載のシステム。
【請求項１６】
前記期待される周期性は、フーリエ変換アルゴリズム、pスコアベースのアルゴリズム、または、指数分布アルゴリズムを使用して決定される、
請求項１１に記載のシステム。
【請求項１７】
前記期待される周期性は、時系列相関を用いて決定される、
請求項１に記載の方法。
【請求項１８】
前記周期的アクティビティ・インスタンス記述子は、正規化技術を使用して生成される、
請求項１１に記載のシステム。
【請求項１９】
前記周期的アクティビティ・インスタンス記述子は、開始時間、終了時間、インターバル値、および、インターバル変動値を使用して、前記第１IoTデバイスのアクティビティを記述するデータ構造である、
請求項１１に記載のシステム。
【請求項２０】
前記周期的アクティビティ・インスタンス記述子は、
アクティビティID、周期的アクティビティID、多次元の統合された特徴値、特徴値範囲、デバイスID、アプリケーションID、ユーザID、サンプリングインターバル、特徴クラス、特徴グループ、特徴プライオリティ、アクティビティを分類するために使用されるアルゴリズム、タイムスタンプ、インターバル値、およびインターバル変動値、
のうち１つ以上を含む、
請求項１１に記載のシステム。
【請求項２１】
第１IoTデバイスおよび第１IoTアプリケーションに関連するIoTイベントをキャプチャするための手段と、
前記IoTイベントからIoTシグナル特徴を生成するための手段であり、少なくともいくつかの前記IoTシグナル特徴は前記第１IoTデバイスおよび前記第１IoTアプリケーションのアクティビティに関連している、手段と、
前記IoTイベントからバックグラウンド・イベント・コンテキストを抽出するための手段と、
前記IoT信号特徴および前記バックグラウンド・イベント・コンテキストに基づいて、周期的アクティビティ・インスタンス記述子を生成するための手段と、
非アクティブIoTイベントから外部コンテキストを抽出するための手段と、
前記周期的アクティビティ・インスタンス記述子および前記外部コンテキストに基づいて、前記第１IoTデバイスの周期的アクティビティを識別するための手段と、
前記第１IoTデバイスの前記周期的アクティビティの期待される周期性を決定するための手段と、
前記第１IoTデバイスのアクティビティを検出するための手段と、
前記第１IoTデバイスの検出された前記アクティビティを前記期待される周期性と一致させるための手段と、
を含む、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、IoTデバイスに係る多次元の周期性検出（multi-dimensional  periodicity  detection）に関する。
【図面の簡単な説明】
【０００２】
【図１】図1は、一つの例示的なモノのインターネット（IoT）ネットワーク・セキュリティシステムのダイアグラムを示している。
【図２】図2は、一つの例示的なオンプレミス（on-prem）IoTコントローラのダイアグラムを示している。
【図３】図3は、一つの例示的なオフプレミス（off-prem）IoTアプリケーション・コントローラのダイアグラムを示している。
【図４】図4は、一つの例示的なサービス指向アーキテクチャ（SOA）を利用するハイブリッドIoTコントローラのダイアグラムを示している。
【図５】図5は、一つの例示的なIoT信号特徴・生成エンジンのダイアグラムを示している。
【図６】図6は、一つの例示的な周期的アクティビティ・定義エンジンのダイアグラムを示している。
【図７】図7は、経時的なイベント検出を例示するグラフを示している。
【図８】図8は、一つの例示的なIoT周期的アクティビティ学習のための方法のフローチャートを示している。
【発明を実施するための形態】
【０００３】
図1は、一つの例示的なモノのインターネット（IoT）ネットワーク・セキュリティシステムのダイアグラムを示している。ダイアグラム100は、コンピュータで読取り可能な媒体（CRM）102、CRM102に結合されたIoTデバイス104-1...104-n(まとめて、「IoTデバイス104」)、CRM102に結合されたIoTコントローラ・エンジン106、CRM102に結合されたイベントキャプチャ・エンジン108、CRM102に結合されたイベント・データストア110、CRM102に結合されたIoT信号特徴・生成エンジン112、CRM102に結合されたIoT信号特徴・データストア114、CRM102に結合された周期的アクティビティ・生成エンジン116、CRM102に結合されたアクティビティ・データストア118、CRM102に結合された異常周期的アクティビティ・IoTネットワーク・脅威評価エンジン120、およびCRM102に結合されたアラート・データストア122、を含んでいる。
【０００４】
この文書で説明されるCRM102および他のコンピュータで読取り可能な媒体は、様々な潜在的に適用可能な技術を表すように意図されている。例えば、CRM102は、ネットワークまたはネットワークの一部分を形成するために使用され得る。デバイス上に２つのコンポーネントが一緒に配置（co-located）されている場合、CRM102は、バス、もしくは、他のデータコンジット（conduit）またはプレーン（plane）含み得る。第１コンポーネントが１つの装置上に配置され、かつ、第２コンポーネントが異なる装置上に配置されている場合、CRM102は、無線または有線のバックエンド・ネットワークまたはLANを含み得る。CRM102は、また、該当する場合、WANまたは他のネットワークの関連部分を含み得る。
【０００５】
この文書において説明されるコンピュータで読取り可能な媒体は、法定の(例えば、合衆国においては、米国特許法第101条（35U.S.C.101）に基づく)全ての媒体を含み、かつ、コンピュータで読取り可能な媒体を含むクレームが有効であるために除外が必要である限りにおいて、本質的に法定以外の全ての媒体を特に除外するように意図されている。既知の法定のコンピュータで読取り可能な媒体は、ハードウェア(例えば、レジスタ、ランダムアクセスメモリ（RAM）、不揮発性（NV）ストレージ)を含むが、ハードウェアに限定されても、または、されなくてもよい。
【０００６】
この文書において説明される、装置、システム、および、コンピュータで読取り可能な媒体は、コンピュータシステム、またはコンピュータシステムの一部分、もしくは複数のコンピュータシステムとして実装され得る。一般的に、コンピュータシステムは、プロセッサ、メモリ、不揮発性ストレージ、および、インターフェイスを含んでいる。典型的なコンピュータシステムは、たいてい、少なくともプロセッサ、メモリ、および、メモリをプロセッサに結合するデバイス（例えば、バス）を含む。プロセッサは、例えば、マイクロプロセッサといった、汎用中央処理装置（CPU）、または、マイクロコントローラといった、特殊目的のプロセッサであり得る。
【０００７】
メモリは、限定ではなく例として、ランダムアクセスメモリ（RAM）を含み得る。ダイナミックRAM（DRAM）およびスタティックRAM（SRAM）といったものである。メモリは、ローカル、リモート、または、分散され得る。バスは、また、プロセッサを不揮発性ストレージに結合することもできる。不揮発性ストレージは、しばしば、磁気フロッピー（登録商標）またはハードディスク、磁気光ディスク、光ディスク、CD-ROM、EPROM、またはEEPROMといった、リードオンリーメモリ（ROM）、磁気または光カード、もしくは、大量のデータのための別の形態のストレージである。このデータの一部分は、しばしば、コンピュータシステム上のソフトウェアの実行中に、メモリの中へ、直接メモリアクセスプロセスによって、書き込まれる。不揮発性ストレージは、ローカル、リモート、または分散され得る。システムはメモリ内で利用可能な全ての適用可能なデータを用いて作成できるので、不揮発性ストレージは任意的である。
【０００８】
ソフトウェアは、典型的に、不揮発性ストレージ内に保管されている。実際、大きなプログラムについては、プログラム全体をメモリ内に保管することすらできないことがある。それにもかかわらず、ソフトウェアを実行するためには、必要であれば、処理のために適したコンピュータで読取り可能なロケーションへ移動されることが理解されるべきであり、そして、説明目的のために、そのロケーションは、この文書においてメモリとして参照されている。たとえソフトウェアが実行のためにメモリに移動された場合でも、プロセッサは、典型的に、ソフトウェアに関連する値を保管するためにハードウェアレジスタを使用し、そして、理想的には、実行を高速化するのに役立つローカルキャッシュを使用する。ここにおいて使用されるように、ソフトウェアプログラムが「コンピュータで読取り可能な記憶媒体において実装される」として参照される場合に、ソフトウェアプログラムは、適用可能な既知または便利なロケーションに(不揮発性ストレージからハードウェアレジスタへ)保管されるものと仮定されている。プログラムに関連する少なくとも１つの値がプロセッサによって読取り可能なレジスタ内に保管される場合に、プロセッサは「プログラムを実行するように構成されている」ものとみなされる。
【０００９】
一つの例示的な動作（operation）において、コンピュータシステムは、ディスク・オペレーティングシステムといった、ファイル管理システムを含むソフトウェアプログラムである、オペレーティングシステム・ソフトウェアによって制御され得る。関連するファイル管理システム・ソフトウェアを伴う一つの例示的なオペレーティングシステム・ソフトウェアは、ワシントン州レドモンドのMicrosoft  CorporationからのWindows(R)として知られるオペレーティングシステム、および、それらの関連するファイル管理システムである。関連するファイル管理システム・ソフトウェアを伴う別の例示的なオペレーティングシステム・ソフトウェアは、Linux(登録商標）オペレーティングシステム及びその関連ファイル管理システムである。ファイル管理システムは、典型的に、不揮発性ストレージ内に保管されており、そして、プロセッサに、不揮発性ストレージにファイルを保管することを含み、データを入力かつ出力し、そして、データをメモリ内に保管するために、オペレーティングシステムによって必要とされる様々なアクト（acts）を実行させる。
【００１０】
バスは、また、プロセッサをインターフェイスに結合することができる。インターフェイスは、１つ以上の入力及び／又は出力(I/O)デバイスを含み得る。実装特有または他の考慮事項に依存して、入出力装置（I/O  devices）は、限定ではなく例として、キーボード、マウスまたは他のポインティングデバイス、ディスクドライブ、プリンタ、スキャナ、および、表示装置を含む、他の入出力装置を含み得る。表示装置は、限定ではなく例として、ブラウン管（CRT）、液晶ディスプレイ（LCD）、または、他のいくつかの既知または便利な表示装置を含み得る。インターフェイスは、モデムまたはネットワークインターフェイスのうち１つ以上を含み得る。モデムまたはネットワークインターフェイスは、コンピュータシステムの一部分であるとみなすことができることが正しく理解されるだろう。インターフェイスは、アナログモデム、ISDNモデム、ケーブルモデム、トークンリングインターフェイス、衛星伝送インターフェイス（例えば、「ダイレクトPC」）、または、コンピュータシステムを他のコンピュータシステムに結合するための他のインターフェイスを含み得る。インターフェイスは、コンピュータシステムおよび他のデバイスが、ネットワーク内で一緒に結合されることを可能にする。
【００１１】
コンピュータシステムは、クラウドベースのコンピューティングシステムの一部分として又はクラウドベースのコンピューティングシステムを介して、互換性があるか、または実装され得る。この文書で使用されるように、クラウドベースのコンピューティングシステムは、仮想化されたコンピューティングリソース、ソフトウェア、及び／又は、情報をエンドユーザデバイスに対して提供するシステムである。コンピューティングリソース、ソフトウェア、及び／又は、情報は、ネットワークといった、エッジデバイスが通信インターフェイスを介してアクセスすることができる、集中化されたサービスおよびリソースを維持することによって仮想化することができ。「クラウド“cloud”」はマーケティング用語であってよく、そして、この文書の目的のためには、ここにおいて記載されているネットワークのいずれかを含み得る。クラウドベースのコンピューティングシステムは、サービスへの加入を伴い、または、ユーティリティ・プライシング・モデル（utility  pricing  model）を使用することができる。ユーザは、エンドユーザ装置上に置かれているウェブブラウザまたは他のコンテナアプリケーションを介して、クラウドベースのコンピューティングシステムのプロトコルにアクセスすることができる。
【００１２】
コンピュータシステムは、エンジンとして、エンジンの一部分として、または複数のエンジンを介して、実装され得る。この文書で使用されるように、エンジンは、１つ以上のプロセッサ又はその一部分を含む。１つ以上のプロセッサの一部分は、任意の１つ以上のプロセッサを含む、ハードウェアの全てより少ないハードウェアのいくらかの部分を含み得る。レジスタのサブセット、マルチスレッドプロセッサの１つ以上のスレッド専用のプロセッサの一部分、タイムスライスといったものであり、その最中に、プロセッサは、エンジンの機能性の一部を実行に全体的または部分的に専用である、等。かくして、第１エンジンおよび第２エンジンは、１つ以上の専用プロセッサを有することができ、もしくは、第１エンジンおよび第２エンジンは、１つ以上のプロセッサを相互に又は他のエンジンと共有することができる。実装特有または他の考慮事項に応じて、エンジンは集中化され、または、その機能性が分散され得る。エンジンは、ハードウェア、ファームウェア、または、プロセッサによる実行のためのコンピュータで読取り可能な媒体に具現化されたソフトウェアを含み得る。プロセッサは、この文書における図を参照して説明されるように、実装されたデータ構造および方法を使用してデータを新しいデータへと変換する。
【００１３】
この文書で説明されるエンジン、又は、この文書で説明されるシステムとデバイスが実装され得るエンジンは、クラウドベースエンジンであり得る。この文書で使用されるように、クラウドベースエンジンは、クラウドベースコンピューティングシステムを使用して、アプリケーション及び／又は機能性を実行することができるエンジンである。アプリケーション及び／又は機能性の全部または一部分は、複数のコンピューティングデバイスにわたり分散され得るものであり、そして、１つのコンピューティングデバイスだけに限定される必要はない。いくつかの実施形態において、クラウドベースエンジンは、エンドユーザのコンピューティングデバイス上にローカルにインストールされた機能性及び／又はモジュールを有することなく、ウェブブラウザまたはコンテナアプリケーションを介してエンドユーザがアクセスする、機能性及び／又はモジュールを実行することができる。
【００１４】
この文書で使用されるように、データストアは、テーブル、コンマで区切られた値(CSV)ファイル、従来のデータベース(例えば、SQL)、または、他の適用可能な既知または便利な組織的フォーマットを含む、任意の適用可能なデータ組織を有するリポジトリを含むように意図されている。データストアは、例えば、特定目的のマシンにおける物理的コンピュータで読取り可能な媒体において具現化されたソフトウェアとして、ファームウェア、ハードウェア、それらの組み合わせ、または、適用可能な既知または便利な装置またはシステムにおいて実装され得る。データベースインターフェイスといった、データストア関連コンポーネントは、データストアの「一部分」、ある他のシステムコンポーネントの一部分、またはそれらの組み合わせとみなされ得る。ただし、データストア関連コンポーネントの物理的なロケーションおよび他の特性は、この文書で説明される技術の理解にとって重要ではない。
【００１５】
データストアは、データ構造を含み得る。この文書で使用されるように、データ構造は、データをコンピュータ内に保管し、組織化する特定の方法と関連付けられており、そうして、所与のコンテキストの中で効率的に使用され得る。データ構造は、一般的に、そのメモリ内の任意のロケーションにおいて、データをフェッチ（fetch）し、かつ、保管するためのコンピュータの能力に基づいており、アドレス、それ自体がメモリに保管され、かつ、プログラムによって操作され得るビット列（bit  string）によって指定されている。従って、いくらかのデータ構造は、算術演算を用いてデータアイテムのアドレスを計算することに基づいており、一方、他のデータ構造は、構造自体の中でデータアイテムのアドレスを保管することに基づいている。多くのデータ構造は、両方の原理を使用しており、ときどき、自明でない方法で組み合わされる。データ構造の実装は、たいてい、その構造のインスタンスを作成し、かつ、操作する一式のプロシージャを書くことを必要とする。この文書で説明される、データストアは、クラウドベースのデータストアであり得る。クラウドベースのデータストアは、クラウドベースのコンピューティングシステムおよびエンジンと互換性のあるデータストアである。
【００１６】
図1の例に戻ると、IoTデバイス104は、目的を持って構築または構成されたIoTデバイスを表すように意図されている。IoTデバイスの例は、サーモスタット、モバイルデバイス、生物学的マネージャ、センサーデバイス、および機能性遂行デバイスを含む。目的を持って構築されたIoTデバイスにおいて、IoTデバイス104は、特定の動作パラメータを有するように構築されている。例えば、温度計は、温度センサからの信号を供給するように構築され得る。目的を持って構成されたIoTデバイスにおいて、IoTデバイス104は、ヒト（human）または人工エージェントからの入力に従って、特定の動作パラメータに応じて動作するように構成され得る。例えば、IoTデバイス104のIoTデバイスは、設定可能な時間に部屋を設定可能な温度まで冷却するために空調機を制御するように構成されたサーモスタットであり得る。他の例は、輸液ポンプ、画像装置(例えば、CTスキャナ、X線装置、画像保存通信システム(PACS)、および、医療におけるデジタル画像および通信(DICOM(R))ワークステーション)を含む。別の例として、エージェントは、IoTデバイスが特定のデータソースと通信すべきではなく、かつ、DICOM画像を見るためだけに使用されるべきであることを指定することができ、そして、IoTデバイスは、特定のデータソースと通信しないように、または、目的を持った構成の一部分としてDICOM画像を見る以外の動作を実行するように構成され得る。IoTデバイスとみなされるように目的を持って構成されたデバイスについて、それは、IoT動作パラメータ内で動作すべきである。IoT動作パラメータからの逸脱は、リスクの増大を生じ、かつ／あるいは、逸脱が確認され得る場合には「ブラウザ使用（“browser  usage”）」といった、アラートをトリガし得る。
【００１７】
特定の実装において、IoTデバイス104は、有線または無線インターフェイスを含み、これを介して、IoTデバイス104は、有線および無線接続にわたりデータを送信および受信することができる。この文書で使用される、用語「実装（“implementation”）」は、例示として説明するのに役立ち、そして、必ずしも限定するものではない実装を意味する。IoTデバイス104は、ネットワークを介してデータを送信する際に使用され得る固有の識別子（identifier）を有し得る。IoTデバイス104の固有の識別子は、インターネットプロトコルバージョン4(以降、「IPv4」として参照される)に従って作成された識別子、または、インターネットプロトコルバージョン6(以降、「IPv6」として参照される)に従って作成された識別子を含み得る。これらの両方のプロトコルバージョンは参照によってここにおいて組み込まれている。実装特有または他の考慮事項に依存して、IoTデバイス104は、適用可能な無線装置プロトコルに従ってデータを受信および送信するための適用可能な通信インターフェイスを含み得る。適用可能な無線装置プロトコルの例は、Wi-Fi、ZigBee(R)、Bluetooth(R)、および、他の適用可能な低消費電力通信規格を含む。
【００１８】
特定の実装において、IoTデバイス104は、ステーションとして動作する。この文書で使用されるように、ステーションは、メディアアクセス制御(MAC)アドレス、および、IEEE802.11標準に準拠する無線媒体に対する物理層(PHY)インターフェイスを有するデバイスとして参照され得る。従って、例えば、適用可能な場合に、ネットワーク装置は、ステーションとして参照され得る。IEEE802.11a-1999、IEEE802.11b-1999、IEEE802.11g-2003、IEEE802.11-2007、およびIEEE802.11n  TGn  Draft8.0(2009)が、参考として組み込まれている。この文書で使用されるように、802.11規格互換または802.11規格準拠のシステムは、組み込まれている書類（document）の要件及び／又は推奨事項、あるいは、書類の以前のドラフトからの要件及び／又は推奨事項のうちの１つ以上に係る少なくともいくらかに準拠しており、そして、Wi-Fiシステムを含んでいる。Wi-Fiは、非技術的な記述であり、IEEE802.11規格、並びに、Wi-Fi  Protected  Access(WPA)およびWPA2セキュリティ規格、および、拡張認証プロトコル(EAP)規格と一般的に相関している。代替的な実施形態において、ステーションは、Wi-FiまたはIEEE802.11とは異なる標準に準拠してよく、「ステーション」以外の何かとして参照されてよく、そして、無線または他のメディアと異なるインターフェイスを有し得る。
【００１９】
特定の実装において、IoTデバイス104は、IEEE802.3に従ってネットワークサービスにアクセスするように構成されている。IEEE802.3は、ワーキンググループ、および、ワーキンググループによって作成されたIEEE標準の集合体であり、有線イーサネットの物理層とデータリンク層のMACを定義している。これは、一般的に、いくつかのワイドエリアネットワーク・アプリケーションを備えるローカルエリアネットワーク技術である。物理的接続は、典型的には、種々のタイプの銅線またはファイバケーブルによって、ノード及び／又はインフラ装置(ハブ、スイッチ、ルータ)間で行われる。IEEE802.3は、IEEE802.1ネットワークアーキテクチャをサポートする技術である。関連技術においてよく知られているように、IEEE802.11は、ワーキンググループ、および、2.4、3.6、および5GHz周波数帯において無線ローカルエリアネットワーク（WLAN）コンピュータ通信を実装するための標準の集合体である。標準IEEE802.11-2007の基本バージョンには、その後の修正がある。これらの標準は、Wi-Fiブランドを使用する無線ネットワーク製品の基礎を提供している。IEEE802.1および802.3は、参照によって組み込まれている。
【００２０】
特定の実装において、IoTデバイス104は、それぞれのパーソナリティを有している。この文書で使用されるように、パーソナリティは、行為（behavior）の集合であり、行為は、特定のタイプのデバイスを記述するために使用される。この文書で使用されるように、行為は、１つ以上の関連するアクティビティのアプリケーション主導の集合体である。パーソナリティは、悪くあり得る。これは、パーソナリティが、後に望ましくない行為を示すような許容できないリスクを表し、または、有するデバイスに属するものとして識別可能であることを意味する。パーソナリティは、良好であり得る、これは、パーソナリティが、後に望ましくない行動を示すことがなく、かつ、期待されないデバイスに属するものとして識別可能であることを意味する。デバイスは、異常な行為を示すことがあり、そして、異常検出は、デバイスが望ましくない行為を示すか否かを判定するために有用なツールであるので、異常な行為は、ときどき、望ましくない行為と関連付けられる。しかしながら、時が経つにつれて、異常な行動は、まだ同定されていないが、潜在的に良好な性格を示すことがある。第１パーソナリティを有するデバイスが異常な行為を示す場合には、いくつかの点では第１パーソナリティと類似しているが、所定の行為が異常ではない第２パーソナリティを定義することが可能であろう。同様に、第1パーソナリティは、以前には異常な行為であったものを異常でない行為として含むように、時間の経過につれてより良好に定義され得るだろう。従って、IoTデバイスを種々のパーソナリティを有するものとして分類することができるだけでなく、パーソナリティが順応性のある定義を有することができ、かつ、時間の経過につれて新たなパーソナリティを定義することができるシステムを提供することが望ましいだろう。
【００２１】
IoTコントローラ・エンジン106は、１つ以上のIoTデバイス104に対してサービスを提供するシステムを表すように意図されている。特定の実装において、アプリケーションの「サーバ部分（“server  part”）」は、仮想マシン及び／又はアプリケーションサーバのクラスタとして実装され得る、IoTコントローラ・エンジン106上で（または、介して）動作し、そして、「クライアント部分（“client  part”）」は、IoTデバイス104のうちの１つ以上において動作する。「サーバ部分」および「クライアント部分」は、まとめてIoTアプリケーションとして参照され、そして、IoTコントローラ・エンジンは、IoTアプリケーション・コントローラ・エンジンとして参照され得る。(「クライアント部分」は、ときどき、サーバのフロントエンドと混同され、その場合に、「クライアント部分」は、サーバのフロントエンドとして特徴付けられ、そして、「サーバ部分」は、サーバのバックエンドとして特徴付けられ得ることが留意され、コンテキストは、これを規定している。)。特定の実装において、IoTコントローラ・エンジン106は、一つの例として図2に示されるように、「オンプレミス（“on-prem”）」に配置されている。
【００２２】
イベントキャプチャ・エンジン108は、CRM102上で発生するイベントを検出することができるエンジンを表すように意図されている。センサの位置は、イベントキャプチャ機能性を決定することができる。例えば、ネットワークイベントは、IoTデバイス104とIoTコントローラ106との間で送信される無線パケットについてのリスニング（listening）によって、または、ロードバランサとフロントエンド・アプリケーション・エンジンとの間の通信についてのリスニングによって検出され得る(例えば、図3を参照)。他の例は、メッセージバス上でのリスニング、シスログ（syslog）メッセージのキャプチャ、等を含む。オンプレミス実装において、イベントキャプチャ・エンジン108は、例えば、パケットスニッフィング（packet  sniffing）をイネーブルするためにミラーを用いて実装され得るが、クラウドにおいては、イベントキャプチャ・エンジン108は、メッセージ「バス（“bus”）」、パケットフォワーダ(例えば、パケットを転送するためのロードバランサ上のスクリプト)、または、ログベースの分析を使用し得る。特定の実装において、イベントキャプチャ・エンジン108は、軽量であり、それは、複数の異なるロケーションにおいて複数の異なるインスペクタ（inspector）によってキャプチャされたイベントを相関させる能力を与えるために望ましいものである。新たにキャプチャされたイベントは、「ロー（“raw”）」イベントとして特徴付けられ、そして、この特徴付けは、何らかの方法でイベントが正規化されるか、または別の方法で抽出されるまで継続することができる。ローイベントは、監査、過去の分析、または、そうでなければローイベントデータの利用を促進することが望ましいか否かに応じて、抽出後のデータストアにおいて維持され、または、されなくてよい。
【００２３】
IoTアプリケーションデータの構造、および、ネットワーク送信においてアプリケーションが搬送するペイロードを理解することは、IoTデバイスの行為をモデル化する際の要素である。既存のIoTセキュリティソリューションは、ネットワークメタデータを用いたモデリングに焦点を当てているが、データ漏洩防止(DLP)といった、より多くのデータ保護が必要とされる状況について使用される場合には、それほど効果的ではない。イベントキャプチャ・エンジン108は、ネットワークペイロードを平文（clear  text）で(例えば、オンプレミス実装について)、または、所望の展開モデルに適したフォーマットで(該当する場合には、異なるイベントフォーマットの正規化を用いて)キャプチャすることによって、これらの欠点に対処する。
【００２４】
図2は、一つの例示的なオンプレミス（on-prem）IoTコントローラのダイアグラム200を示している。ダイアグラム200は、LAN202、LAN202に結合されたIoTデバイス204、LAN202に結合されたIoTコントローラ・エンジン206、IoTコントローラ・エンジン206に結合されたサービス208-1からサービス208-1まで(サービス208)、LAN202に結合されたファイアウォール210、ファイアウォール210に結合されたWAN212、を含んでいる。IoTデバイス204、IoTコントローラ・エンジン206、サービス208、およびファイアウォール210は、また、LAN202上に「オン（“on”）」または「オンプレミス（“on-prem”）」として参照され得ることに留意されたい。
【００２５】
LAN202は、IoTデバイス、IoTコントローラ・エンジン、および、他の可能性のある装置に係る比較的ローカルなネットワークを表すように意図されている。エンタープライズネットワークは、WANセグメントにわたり結合された地理的に分散されたLANを含み得ることが留意されるべきである。分散型エンタープライズネットワーク（distributed  enterprise  network）において、ゲートウェイは、各LANにおいてローカルであってよく(各LANは、IEEE802.11用語ではベーシックサービスセット（Basic  Service  Set、BSS)として参照されるが、ここでは明示的な要件は示唆されていない)、または、例えばVLANトンネリングを使用してローカライズされてよいが(接続されたLANは、ときどき、IEEE802.11用語では拡張サービスセット（Extended  Service  Set、ESS)として参照されるが、ここでは明示的な要件は示唆されていない)、一般的に、地理的に分散されたエンタープライズネットワークにおいて種々のLANを接続するためには何らかの形態のゲートウェイ機能性が依然として必要とされる。
【００２６】
IoTデバイス204は、図1を参照してIoTデバイス104について説明したものと同様な方法で実装され得る。IoTコントローラ・エンジン206は、図1を参照してIoTコントローラ106について説明したものと同様な方法で実装することができる。サービス208は、IoTコントローラ・エンジン206を介してIoTデバイス204に対して提供されるオンプレミス・サービスを表すように意図されている。ファイアウォール210は、LAN202のオンプレミス装置(IoTデバイス204およびIoTコントローラ・エンジン206といったもの)と、WAN212のオフプレミス装置(一般的には、LANを含む、他のネットワークを含むが、図示されていない)との間に置かれた一つの例示的な装置を表すように意図されている。
【００２７】
特定の実装において、インスペクタは、矢印214によって識別されるロケーションでLAN202に結合されている(すなわち、インスペクタは、LAN202上に「オン」であり、そして、オンプレミス・インスペクタとして参照され得る)。そうした実装においては、IoTデバイス204とIoTコントローラ・エンジン206との間で、ネットワークトラフィックについて平文で送信されることは珍しいことではないだろう。例えば、インスペクタは、IoTデバイス204とIoTコントローラ・エンジン206との間のネットワークトラフィックを検出することができるスニファ（sniffer）として実装され得る。
【００２８】
再び、図1の例を参照すると、特定の実装において、IoTコントローラ・エンジン106およびイベントキャプチャ・エンジン108は「オフプレミス（“off-prem”）」に配置されており、その一つの例は、図3の実施例として提供されている。加えて、イベントキャプチャ・エンジン108は、例えば、IoTデバイスへの送信、または、IoTデバイスからの送信をモニタリングするオンプレミス・コンポーネントを有し得る。
【００２９】
図3は、一つの例示的なオフプレミス・IoTアプリケーション・コントローラのダイアグラム300を示している。ダイアグラム300は、LAN302、LAN302に結合されたIoTデバイス304、LAN302に結合されたファイアウォール306、ファイアウォール306に結合されたWAN308、WAN308に結合されたIoTアプリケーション・コントローラ310、を含んでいる。IoTデバイス304およびファイアウォール306は、また、LAN302上に「オン（“on”）」または「オンプレミス（“on-prem”）」として参照され、一方で、IoTアプリケーション・コントローラ・エンジン310は、また、WAN308上に「オン（“on”）」(かつ、LAN302上ではなく)または「オフプレミス（“off-prem”）」としても参照され得ることに留意されたい。特定の実装において、IoTアプリケーション・コントローラ310は、クラウド内に実装されている。
【００３０】
LAN302は、IoTデバイスの比較的ローカルなネットワークおよび潜在的に他のデバイスを表すように意図されている。IoTデバイス304は、図1を参照してIoTデバイス104について説明したものと同様な方法で実装され得る。ファイアウォール306は、LAN302のオンプレミス装置(IoTデバイス304といったもの)と、WAN308上のオフプレミス装置(IoTアプリケーション・コントローラ・エンジン310といったもの)との間に置かれた一つの例示的な装置を表すように意図されている。WAN308とIoTアプリケーション・コントローラ・エンジン310との間のリンクは、例えば、クリア・テキスト・プロトコルを有する仮想プライベート・ネットワーク(VPN)エンジン(図示なし)を介して達成され得る(RESTfulインターフェイスは可能性が低いだろうが、必ずしも適用不可能ではない)。
【００３１】
IoTアプリケーション・コントローラ・エンジン310は、図1を参照してIoTコントローラ106について説明したものと同様な方法で実装され得る。ダイアグラム300において、IoTアプリケーション・コントローラ・エンジン306は、ロードバランサ312、ロードバランサ312に結合されたフロントエンド・アプリケーション・エンジン314、フロントエンド・アプリケーション・エンジン314に結合されたサービス316-1からサービス316-nまで(まとめて、サービス316)、ロードバランサ312およびフロントエンド・アプリケーション・エンジン314に結合されたAPIゲートウェイ318、を含んでいる。
【００３２】
ロードバランサ312は、サーバサイド・エンジンを表すように意図されており、それを介して外部クライアントがサービスに結合され得る。特定の実装において、ロードバランサ312は、外部クライアントがサービスにアクセスするために接続するポートをリスニングする。ロードバランサは、サービスに関連するバックエンドサーバに対してリクエストを転送する。有利なことに、ロードバランサ312は、IoTデバイス304がバックエンドサーバに直接的にコンタクトすることを防止する。ロードバランサ312は、故障の単一ポイントとすることを回避するように実装され得る。所与のアプリケーションについて望ましい場合にセッション永続データ（session  persistence  data）を複製することができるエンジンの高可用性ペアとして実装することによる、といったものである。
【００３３】
フロントエンド・アプリケーション・エンジン314は、ロードバランサ312(クライアント側)とサービス316(サーバ側)との間のインターフェイスを表すように意図されている。サービス316は、オフプレミス・サービス、または、特定の実装においては、オフプレミス・アプリケーション・サービスとして参照され得る。
【００３４】
特定の実装において、サービス316は、サービスが微細化（fine-grained）され、そして、プロトコルが軽量である、マイクロサービス（microservice）アーキテクチャの一部分を表している。マイクロサービスベースのアーキテクチャは、連続的な配信と展開を可能にし、そして、しばしば、以下のものを使用して、目標を達成するために、ネットワーク上で通信するプロセスを含んでいる。HTTPといった技術に依存しない（technology-agnostic）プロトコル(しかし、共有メモリといった、他の種類のプロセス間（inter-process）通信メカニズムを含み得る)、独立して展開可能なサービス、容易に交換可能なサービス、機能を中心に組織化されたサービス(例えば、ユーザインターフェイス・フロントエンド、推奨（recommendation）、ロジスティックス、請求（billing）、等)、最良に適合するものに応じて、異なるプログラミング言語、データベース、ハードウェア、およびソフトウェア環境を使用して実施されるサービス、及び／又は、メッセージング可能な、コンテキストにより制限され、自律的に開発され、独立して展開可能な、分散化され、そして、自動化されたプロセスによって構築され、かつ、リリースされる、比較的小規模なサービス、である。一般的に、マイクロサービスベースのアーキテクチャは、分散構造を自然に実行し、連続的な配信ソフトウェア開発プロセスにふさわしく、細分化されたインターフェイス、ビジネス主導の展開、クラウドアプリケーションアーキテクチャ、ポリグロット（polyglot）プログラミングおよび持続性、軽量コンテナ開発、分散化された連続的な配信、および全体的なサービスモニタリングを伴うDevOps、といった原理に従い、かつ／あるいは、スケーラビリティに有益な特性を提供する。
【００３５】
APIゲートウェイ318は、ロードバランサ312とサービス316との間のインターフェイスを表すように意図されているが、APIフロントエンドとして機能し、APIリクエストを受信する。特定の実装において、APIゲートウェイ318は、スロットリング（throttling）およびセキュリティポリシを実行し、リクエストを(バックエンド)サービス316へパス（pass）し、レスポンスをIoTデバイス304へパスする。APIゲートウェイ318は、また、その場で（on  the  fly）リクエストおよびレスポンスを編成かつ修正し、分析データを収集し、キャッシュを提供し、そして、認証、承認、セキュリティ、監査、および規制コンプライアンスをサポートするための変換エンジンを含んでよく、または、含まなくてもよい。
【００３６】
特定の実装において、イベントキャプチャ・エンジン(オフプレミスイベントキャプチャ・エンジン、または、イベントキャプチャ・エンジンのオフプレミスコンポーネントとして参照され得るもの)は、矢印320によって識別されるロケーションでIoTアプリケーション・コントローラ・エンジン310に対して動作上接続されている。そうした実装において、インスペクタは、ロードバランサ312(かつ、アプリケーション・ロードバランサ・インスペクタとして参照され得るもの)の「背後（“behind”）」に配置され、そして、インスペクタは、フロントエンド・アプリケーション・エンジン314とサービス316それぞれとの間に配置されている(例えば、サービス316それぞれの前にインスペクタが存在しており、それはアプリケーション・サービス・インスペクタとして参照され得る)。背後とは、ロードバランサ312がインスペクタとIoTデバイス304との間にあることを意味するように意図されている。
【００３７】
もう一度、図1の例を参照すると、特定の実装において、IoTコントローラ・エンジン106およびイベントキャプチャ・エンジン108は、「オンプレミス」および「オフプレミス」の両方のコンポーネントを有しており、その一つの例が、図4の例として提供されている。
【００３８】
図4は、一つの例示的なサービス指向アーキテクチャ（SOA）を利用するハイブリッドIoTコントローラのダイアグラム400を示している。この文書で使用されるように、SOAは、特定の結果を伴うビジネスアクティビティを論理的に表しており、自己充足的（self-contained）であり、サービスリクエスタのブラックボックスであり、そして、他の根底にある（underlying）サービスで構成され得る。ダイアグラム400は、LAN402、LAN402に結合されたIoTデバイス404、LAN402に結合されたIoTコントローラ・エンジン406、IoTコントローラ・エンジン406に結合されたサービス408-1からサービス408-nまで(まとめて、サービス408)、LAN402に結合されたファイアウォール410、ファイアウォール410に結合されたWAN412、WAN412に結合されたIoTアプリケーション・コントローラ414、を含んでいる。IoTデバイス404、IoTコントローラ・エンジン406、およびファイアウォール410は、また、LAN402上に「オン（“on”）」であり、または「オンプレミス（“on-prem”）」としても参照され、一方で、IoTアプリケーション・コントローラ・エンジン414は、また、WAN410上に「オン」(かつ、LAN402上ではなく)または「オフプレミス（“off-prem”）」としても参照され得ることに留意されたい。サービス408は、また、オンプレミス・サービスとしても参照される。
【００３９】
LAN402は、IoTデバイスの比較的ローカルなネットワークおよび潜在的に他のデバイスを表すように意図されている。IoTデバイス404は、図1を参照してIoTデバイス104について説明したものと同様な方法で実装され得る。IoTコントローラ・エンジン406は、図1を参照してIoTコントローラ106について説明したのと同様な方法で、または、図2を参照してIoTコントローラ206について説明したのと同様な方法で実装され得る。ファイアウォール410は、LAN402のオンプレミス装置(IoTデバイス404またはIoTコントローラ・エンジン406といったもの)と、WAN412のオフプレミス装置(IoTアプリケーション・コントローラ・エンジン414といったもの)との間に置かれた一つの例示的な装置を表すように意図されている。
【００４０】
IoTアプリケーション・コントローラ・エンジン414は、図1を参照してIoTコントローラ106、または、図3を参照してIoTアプリケーション・コントローラ310について説明したのと同様な方法で実装され得る。ダイアグラム400において、IoTアプリケーション・コントローラ・エンジン414は、ロードバランサ416、ロードバランサ416に結合されたフロントエンド・アプリケーション・エンジン418、フロントエンド・アプリケーション・エンジン418に結合されたサービス420-1からサービス420-nまで(まとめて、サービス420)、ロードバランサ416およびフロントエンド・アプリケーション・エンジン418に結合されたAPIゲートウェイ422、を含んでいる。
【００４１】
フロントエンド・アプリケーション・エンジン418は、サービス420へのフロントエンド・インターフェイスを表すように意図されている。(フロントエンド・アプリケーション・エンジン418およびサービス420は、まとめて、アプリケーションサーバとして参照され得る。)特定の実装において、フロントエンド・アプリケーション・エンジン418は、例えば、シンプルオブジェクトアクセスプロトコル（SOAP）に基づいて、ウェブサーバを含み得る。代替的な実装は、メッセージングサーバ、表現的状態転送(RESTful)HTTPサーバ、OPC統一アーキテクチャ(OPC-UA)、Windows通信基盤(WCF)、Apache  Thrift、および、SORCERを含んでいる。
【００４２】
特定の実装においては、イベントキャプチャ・エンジンが、矢印424によって識別されるロケーションでLAN402に結合されている(すなわち、インスペクタは、LAN402上に「オン」であり、そして、オンプレミス・インスペクタとして参照され得る)。そうした実装においては、IoTデバイス404とIoTコントローラ・エンジン406との間で、ネットワークトラフィックについて平文で送信されることは珍しいことではないだろう。例えば、インスペクタは、IoTデバイス404とIoTコントローラ・エンジン406との間のネットワークトラフィックを検出することができるスニファとして実装され得る。
【００４３】
特定の実装において、イベントキャプチャ・エンジンは、矢印426によって識別されるロケーションで、IoTアプリケーション・コントローラ・エンジン414に対して動作上接続されている。そうした実装において、インスペクタは、ロードバランサ416(かつ、アプリケーション・ロードバランサ・インスペクタとして参照され得るもの)の「背後（“behind”）」に配置され、そして、インスペクタは、フロントエンド・アプリケーション・エンジン418とサービス420それぞれとの間に配置されている(例えば、サービス420それぞれの前にインスペクタが存在しており、それはアプリケーション・サービス・インスペクタとして参照され得る)。背後とは、ロードバランサ416がインスペクタとIoTデバイス404との間にあることを意味するように意図されている。
【００４４】
再び、図1の例を参照すると、イベントキャプチャ・エンジン108は、図2から図4を参照して説明されるように、ネットワークの全体を通じて様々なロケーションに配置された一式のインスペクタを含むように意図されている。実装特有、コンフィグレーション特有、または他の要因に依存して、イベントキャプチャ・エンジン108、または少なくともそれらのインスペクタについては、軽量であることが望ましく、これにより、できるだけ多くのインスペクタを困難なく展開し、かつ、関連するイベントを複数のインスペクタにわたるアクティビティに相関させることをより容易にしている。特定の実装において、関連するイベント生成コンポーネントは、オンプレミス・インスペクタ、アプリケーション・ロードバランサ・インスペクタ、及び／又は、アプリケーションサービス・インスペクタを含み得る、それぞれのインスペクタと一緒に配置されている。
【００４５】
イベント・データストア110は、ローイベント（raw  event）から、正規化され、集約され、強化され、かつ／あるいは、別の方法で変換されたイベントまで、変換の任意の段階におけるイベントのデータストアを表すように意図されている。IoTデバイスに対する識別の最小単位は、イベントとして特徴付けされ得る。イベントデータ構造は、ローカルデータベース・アクセス・イベント、アクティブ・クエリを介してログメッセージから獲得されたイベント、等といった、ネットワークイベントではないイベントの表現を含み、または、含まなくてもよい。IoTデバイス104のうちのIoTデバイスのネットワークセッションは、ネットワークイベントであり(または、永続的ネットワークセッションは、一連のネットワークイベントの中へ「チャンク（“chunked”）」され得る)ので、IoTデバイスは、IoTデバイスのネットワークイベントを表すイベント・データストア110内の関連イベントデータ構造に少なくとも部分的に一致するイベントによって定義されるアクティビティに参加するものとして識別され得る。この文書で使用されるように、アクティビティ・データ構造は、イベントのラベル付きコレクションである。IoTアプリケーションの行為は、IoTデバイスの行為とは十分に異なり、IoTアプリケーションについて識別の最小の有意義な単位は、アクティビティ(例えば、ファイルダウンロード)である。アクティビティの例において、イベントキャプチャ・エンジン108は、キャプチャされたイベントをイベント・データストア110内に保管する。これは、最初に「ローイベント」として参照され得る。
【００４６】
IoT信号特徴・生成エンジン112は、イベント・データストア110内のローイベントをIoT信号特徴へと変換するエンジンを表すように意図されている。特定の実装において、IoT信号特徴・生成エンジン112は、便宜のためイベントキャプチャ・エンジン108と一緒に配置されている。例えば、キャプチャの際にイベントを正規化し、正規化されたイベントについて少なくとも一部分の集約を実行し、そして、正規化され(かつ、潜在的に集約された)イベントから少なくともいくつかのシグナル特徴を抽出すること、が便利である。代替的または追加的に、集約および特徴抽出は、イベントキャプチャ・エンジン108に関してリモートにあるIoT信号特徴・生成エンジン112のコンポーネントを介して行われる。
【００４７】
図5は、一つの例示的なIoT信号特徴・生成エンジンのダイアグラム500を示している。ダイアグラム500は、ローイベント・データストア502、ローイベント・データストア502に結合されたイベント正規化・エンジン504、イベント正規化・エンジン504に結合されたドメイン・データストア506、イベント正規化・エンジン504に結合された正規化イベント・データストア508、ドメイン・データストア506および正規化イベント・データストア508に結合されたイベント集約・エンジン510、イベント集約・エンジン510に結合された集約イベント・データストア512、ドメイン・データストア506および集約イベント・データストア512に結合されたIoT信号特徴・抽出エンジン514、IoT信号特徴・抽出エンジン514に結合されたIoT信号特徴・データストア516、を含んでいる。ダイアグラムに示されたコンポーネントのいくつかは、全体的または部分的に、他のコンポーネントとは異なる物理的ロケーションにおいて実装され得る。
【００４８】
ローイベント・データストア502は、様々な種類のイベントを表すように意図されている。イベントの重要なサブクラスは、ネットワークセッションイベント、または、「ネットワークイベント（“network  events”）」である。いくつかの実装においては、ネットワークイベントキャプチャがパケットまたはフレームであるので、「パケットベース（“packet-base”）」(または「フレームベース“frame-base”）」)イベントとして適切に参照され得る。特定の実装において、離散的ネットワークイベント（discrete  network  event）はネットワークセッションである。代替的または追加的に、離散的ネットワークイベントは、チャンク（chunk）へと分割された永続的ネットワークセッションの一部分であり、ここで、ネットワークセッションのチャンクは、全体として、ネットワークセッションを含む。イベントの別の潜在的なサブクラスは、軽量パブリッシュ／サブスクライブ・メッセージング・トランスポート(例えば、メッセージ・キューイング・テレメトリー・トランスポート（MQTT）)を使用するメッセージといった、メッセージ・トランスポート・イベントを含む。イベントの別の潜在的なサブクラスは、メッセージジェネレータを分離するための標準を使用するメッセージ、メッセージを保管するシステム、そして、メッセージ分析およびレポートエンジン(例えば、シスログ（syslog）)といった、メッセージログイベントを含む。ローイベント・データストア502は、正規化イベント・データストア508、集約イベント・データストア512、およびIoT信号特徴・データストア516といった、他のデータストアを組み込む「スーパー（“super”）」データストア(図1のイベント・データストア110といったもの)の一部分と見なされ得る。
【００４９】
イベント正規化・エンジン504は、異種のフォーマットのイベントを正規化するエンジンを表すように意図されている。イベント正規化・エンジン504は、イベントについて正規化(例えば、標準化)フォーマットを決定するために、ドメイン・データストア506からの情報を使用し、そして、正規化イベント・データストア508の中へ保管するために、ローイベント・データストア502からのイベントを正規化(例えば、変換)する。特定の実装において、イベントは、タイムスタンプ、タグ付け（tagging）(例えば、ドメイン・データストア506から)、ID(例えば、ユーザIDまたはイベントID)、等のうち１つ以上を使用して正規化される。イベントを正規化することは、後に、エンジンが、例えば、集約目的のために、同一条件で（apple-to-apple）イベントの比較を行うことを可能にする。例えば、ネットワークイベントだけが集約される実装において、正規化は任意的とみなされてよく、または、みなされなくてもよい。
【００５０】
イベント集約・エンジン510は、正規化イベント・データストア508からの正規化イベントを他の関連イベントと集約するためのエンジンを表すように意図されている。特定の実装において、他の関連イベントは、また、正規化されたイベント・データストア508内の正規化されたイベントでもある。関連イベントは、例えば、永続的セッションに係る複数の離散的ネットワークイベント、同じソース、ユーザ、時間、またはアプリケーションに関連するイベント、(例えば、ドメイン知識に基づいて)アクティビティ(例えば、ログイン、ダウンロード、ストリーミング、または他の可能なアクティビティに関連するイベント、IoTデバイスプロファイルに関連するイベント、時系列レベルで関連するイベント、等を含み得る。イベント集約・エンジン510は、集約イベント・データストア512内に集約イベントを保管する。「集約イベント（“aggregated  event”）」が、１つ以上の正規化イベントを含み、そして、コンテキストが、１つの集約イベントが１つの正規化イベントを含むか、または、１つの集約イベントが複数の正規化イベントを含むかどうかを決定することに留意する。
【００５１】
IoT信号特徴・抽出エンジン514は、IoTデバイスに関連する信号から特徴を抽出するためのエンジンを表すように意図されている。特定の実装においては、所与の信号が複数の関連する特徴を有し得るが、信号は、周期性を決定する目的で、最小、または原子（atomic）イベントとして扱われる。例えば、５分間の変換は、５分間それぞれに関連する５つのシグナル特徴を有するものとして扱うことができる。特徴値は、特徴自体に対応しているデータサンプルを含む。IoT信号特徴・抽出エンジン514は、IoT信号特徴・データストア516内に特徴値を保管する。
【００５２】
動作の例において、イベントは、ネットワークセッションイベントであると想定されている。イベント正規化・エンジン504は、(該当する場合)タイムスパン(例えば、５分間インターバル)にわたりイベントのボリューム(例えば、バイト数)を正規化する。イベント集約・エンジン510は、タイムスパンの最中にキャプチャされた１つ以上のイベントを集約する。集約されていないイベントは、任意の集約されたイベントと共に、IoT信号特徴・抽出エンジン514によって、依然として分析され得ることに気付くだろう。抽出された信号特徴は、集約、正規化、濃縮、または、別の方法で変換されたイベントとして特徴付けることができ、図6を参照して説明されるように、周期的アクティビティを識別するために使用される。
【００５３】
図6は、一つの例示的な周期的アクティビティ・定義エンジンのダイアグラム600を示している。ダイアグラム600は、IoT信号特徴・データストア602、IoT信号特徴・データストア602に結合されたIoT信号・生成エンジン604、IoT信号・生成エンジン604に結合されたバックグラウンド・イベント・コンテキスト・データストア606、IoT信号・生成エンジン604に結合された信号データストア608-1から信号データストア608-nまで(まとめて、信号データストア608)、信号データストア608に結合された周期性・発見エンジン610、周期性・発見エンジン610に結合された周期的アクティビティ・インスタンス・データストア612-1から周期的アクティビティ・インスタンス・データストア612-nまで(まとめて、周期的アクティビティ・インスタンス・データストア612)、周期的アクティビティ・インスタンス・データストア612に結合された周期的アクティビティ・生成エンジン614、周期的アクティビティ・生成エンジン614に結合された外部コンテキスト・データストア616-1から外部コンテキスト・データストア616-nまで(まとめて、外部コンテキスト・データストア616)、周期的アクティビティ・生成エンジン614に結合された周期的アクティビティ・データストア618、および、外部コンテキスト・データストア616に結合されたコンテキスト・抽出エンジン620、を含んでいる。
【００５４】
信号特徴・データストア602は、開始時間値、終了時間値、インターバル値、およびインターバル変動(ここにおいては時間デルタとして参照される)値、を含むイベントデータ構造のデータストアを表すように意図されている。(この段階では、値が関連するものとして理解されてよく、または、されなくてもよいことに気付くだろう。)正規化は、異なるタイプのイベント(例えば、ネットワーク、メッセージキュー、シスログ、等)について周期性記述子（periodicity  descriptors）の生成を促進することができる。特定の実装において、開始時間は、周期的なアクティビティの開始に起因するタイムスタンプであり(これは、アクティビティの最初に検出されたイベントの開始と同じであり得る)、終了時間は、その周期的なアクティビティに対する終了に起因するタイムスタンプであり(その値は、アクティビティが終了する時間まで、ブランク（blank）またはヌル（null）とみなされ得る)、インターバルは、２つの周期的なイベント(または２つの集約されたイベント)の間の時間スパンであり、そして、時間デルタは、そのインターバルからの許容可能な偏差（deviation）である。「許容可能な偏差」により意味するものは、検出されたイベント間のインターバルがいくらか変化したとしても、周期性の帰属が適用可能であることである。ただし、システムの洗練度にどれだけ依存するかによる(一般的に、周期的イベント間のインターバルの時間デルタが大きいほど、周期性を識別することがより困難である)。イベントに係る所与の(潜在的に周期的な)シーケンスに対する信号特徴は、従って、開始時間によって定義された時間ウィンドウ内のイベントキューの数として特徴付けられ、そして、時間デルタ内にある、期待されるインターバルからの潜在的な偏差を伴う時間インターバルによって分離され得る。実装特有、コンフィグレーション特有、または他の要因に依存して、アクティビティは、複数の異なる周期性を有することができ、それらは別々に追跡され、そして、相関され得る。
【００５５】
特定の実装において、インターバル値および時間デルタ値は、最小インターバルの後の最大時間として最小インターバルおよび時間デルタとして実装され、その期間の最中にイベントが発生する(例えば、次のイベントの開始時間は、指示されたインターバルの時間に、または、指示されたインターバルの後で、発生しなければならないが、インターバル＋時間デルタの時間の前である)。代替的に、インターバルは、最大インターバルとして実装され、そして、時間デルタは、最大インターバルの前の時間フレームとして実装される。さらに別の代替として、インターバルは、予測インターバルとして実装され、そして、時間デルタは、予測インターバルの前または後の許容可能な時間として実装され、その最中に、周期的イベントが発生する(そして、この代替において、時間デルタは、２つの値を有し、または、有さなくてもよい。１つは、指定されたインターバルの前について、かつ、１つは、その後についてである)。
【００５６】
IoT信号・生成エンジン604は、信号を生成するために、IoT信号特徴・データストア602における信号特徴およびバックグラウンド・イベント・コンテキスト・データストア606からのコンテキストを使用する。バックグラウンド・イベント・コンテキスト・データストア606は、IoTデバイス識別子（ID）、アプリケーションID、およびボリュームを含むデータストアを表すように意図されており、バックグラウンド・イベント・コンテキストは、また、ユーザIDおよびソースIDを含み、または、含まなくてもよい。代替的に、ドメイン・データストア(例えば、図5を参照のこと)は、バックグラウンド・イベント・コンテキストを信号特徴に明示的に埋め込むことができ、バックグラウンド・イベント・コンテキスト・データストア606をIoT信号特徴・データストア602の一部分に論理的にレンダリングすることができる。
【００５７】
シグナルは、イベント関連閾値（event  relevant  threshold）を超えるアクティビティ・タイムライン上の１つ以上の時間相関イベントとして定義され得る。特定の実装において、イベント関連閾値はサンプルから訓練（trained）される。実装、コンフィグレーション、または他の要因に依存して、パラメータは、イベント関連閾値に影響し得る(例えば、異なる閾値が異なる特徴について適用され得るだろう)。(後述するように、アクティビティは、アクティビティ・タイムライン上の１つ以上の時間相関イベント、プラス（plus）コンテキスト、として定義され得る)。特定の実装において、信号は、時間スパンにわたる、IoTデバイスおよびソースに対するアプリケーション特有のブーリアン（Boolean）配列として、表現される。この特定の実装においては、信号がアプリケーション特有であるため、第１アプリケーションと相関するイベントは、第２アプリケーションのアレイの一部分ではない。
【００５８】
IoT信号・生成エンジン604は、信号データストア608内に信号を保管する。例示的な便宜のために、信号データストア608は、複数の別個のデータストア608-1から608-nまでとして表されており、それぞれが、特定のアプリケーション、IoTデバイス、およびソースに関連する信号を表すように意図されている。周期的でない信号は、周期性発見の目的でノイズとして扱うことができる(ただし、それらは、もちろん、IoTネットワーク分析またはセキュリティの他の態様について関連し得る)。特定の実装において、信号データストア608のデータ構造は、周期性・発見エンジン610へと１つずつ供給される(履歴)イベントに対応するブーリアン配列を含む。
【００５９】
周期性・発見エンジン610は、IoTデバイス、アプリケーション、およびソースに関連する周期性を発見するために、IoTデバイス、アプリケーション、およびソースに関連する様々な時間スパンを分析するエンジンを表すように意図されている。有利なことに、周期性・発見エンジン610は様々な時間スパンを分析するので、必ずしも２回目の時間スパンにわたり反復されない、１回目の時間スパンの中の周期性を検出することが可能である。例えば、アクティビティは、１日だけの期間スパンによっては検出されないであろう毎週の周期性を有し得る。セキュリティエージェントは、毎日(第１時間スパン)報告し、かつ、毎週(第２時間スパン)バージョンのアップデートをチェックし得る。それで、単一のアプリケーションは、異なる時間スパンにわたり検出可能な複数の異なる周期性を有し得るだろう。後述するように、このことは、第１アクティビティ(例えば、毎日のレポート)および第２アクティビティ(例えば、毎週のチェック)がもはや期待されるように検出できない場合に、相関および異なる考察を可能にする。
【００６０】
特定の実装において、周期性・発見エンジン610は、周期性を識別するためにフーリエ変換アルゴリズムを使用する。インターバルＮ：ｆｋ＝Ｋ／Ｎにおいてｓｎの離散フーリエ変換(DFT)を計算することが可能である。ここで、Ｎはサンプルであり、Ｋはセグメントである。フーリエ変換アルゴリズムは、比較的小さなインターバルで正確であり得るが、IoTは比較的安定なので(かつ、DFTはノイズから信号を区別できないので)、これはIoTアプリケーションにおいて絶対に必要なものではない。従って、実験によって有利に確認されるように、潜在的により望ましい代替は、それ自体におけるｐ-スコア、もしくは、DFT後のPSDまたは非ガウス分布(ピークがどこにあるかを見つけるために使用されるもの)を使用することである。
【００６１】
ｐ-スコアベースのアルゴリズムについて、タイムライン、Ｔ、は、サンプル、
Ｎ、について、セグメント、Ｋ、へと分割される。当業者に理解される注目すべき式は、Ｐｉ＝(タイムスロットｉ内のセグメント)／Ｋ、および、Ｐｋ＝Δｔ／ｆｋを含み、ここで、Δｔ＝５分、１時間、または１日(または、有用であると考えられる他の時間インターバル)であり、ｋ＝連続したｎサンプル、Ｋ・ｎ＝Ｎ、および、ｆｋ＝Ｋ／Ｎを含む。動作の一つの例においては、期間が「ｎ」である(注：ｎはサンプルインターバルｓ０からｓｉ、ｓｉ−１までであり、ここで、ｉはサンプルインターバルインデックスである。かつ、Ｐ｛ｉ｝＝Ｓ／Ｋであり、ここで、Ｓはｓｉにおけるセグメントの数である。)と仮定し、そして、ｎ＝１からおそらく１週間分のサンプルを試み、開始時間を決定するために確率を使用する。
【００６２】
また、指数分布または他の回帰アルゴリズムを使用することもできる。例えば、別の代替として、遅延コピーとの関係を見つけるために自己相関(時系列相関)だけを使用することができる。信号をシフトし、かつ、信号の数をチェックした後で、シフト（shifting）は、オーバーラップが存在する場合に、同じ数のより大きな信号を生成する。この技法は、また、他のアルゴリズムと組み合わせても使用され得る。いずれの場合でも、閾値は、サンプルから訓練され、そして、図7の例で示されるように、アルゴリズムに組み込まれて、信号の検出を可能にする。
【００６３】
図7は、経時的なイベント検出を例示するグラフ700を示している。グラフ700は、時間軸702および確率軸704を含む。時間が経過すると、イベントが発生し、それは、時間軸702上の単位と概念的に同等な開始および停止時間を伴うグラフ上のスパイクまたは長方形として表現され得る。より広いイベントは、所望の概念化に応じて、より多くのバイト又はより多くのメッセージの送信として特徴付けられ得る。より背の高い（taller）イベントは、より独特である(例えば、より異常である)として特徴付けることができ、これは、概念的に、確率軸704上の単位と相関し得る。
【００６４】
説明目的のために、グラフ700には、イベント706および通常アクティビティ708がある。イベント706は、閾値710を超えているので、通常アクティビティ708から区別される。図7の例において、イベント706のいくつかは、アクティビティ(例えば、FTP)に関連するシグナル712のコンポーネントである。他のイベント706は、いくつかの他のアクティビティに関連する信号714のコンポーネント(図7の例において、信号714は、図示されたタイムラインにおいて単一のイベントを含む)。通常アクティビティ708は、「バックグラウンド・アクティビティ（“background  activities”）」として特徴付けられ、それらは特徴値が閾値710を超えないものである。バックグラウンド・アクティビティは、いつでも発生する通常のイベントを含み得るが、異常なアクティビティを構成するものを見つけ出すために使用され得るという意味でコンテキスト上（contextual）のものになる。図7に示されるように、信号は、閾値を超えるアクティビティ・タイムライン上の１つ以上の時間相関イベントとして特徴付けられ得る。信号は「アクティビティ」と関連付けられ得るが、アクティビティは、コンテキストにおける（in  context）アクティビティのタイムライン上の１つ以上の時間相関イベントであることが理解されるべきである。それで、用語アクティビティは、最終的にはアクティビティとして識別されるので、信号を記述するために使用され得るが、アクティビティは、信号について具体化（flesh  out）されてよく、または、未だされてなくてもよい。
【００６５】
再び、図6の例を参照すると、周期性・発見エンジン610の出力は、特定のIoTデバイス、ソース、およびアプリケーションの実際の周期性であり、それらは、周期的インスタンス・データストア612に保管される。この段階において、開始時間値、終了時間値、インターバル値、およびインターバル変動(ここにおいては、時間デルタとして参照される)値は、示されたパラメータ内にある特性を有する所与の信号について認識される(ただし、アクティビティが実際に停止するまで終了時間はヌルのままである)。周期的アクティビティ・インスタンス記述子は、その開始時間、終了時間、インターバル、および時間デルタを使用してアクティビティを記述する周期的アクティビティ・インスタンス・データストア612に保管されたデータ構造として定義され得る。
【００６６】
周期的アクティビティ・生成エンジン614は、周期的アクティビティ・データストア618内に保管するための周期的アクティビティ・データ構造を生成するために外部コンテキスト・データストア616を使用するエンジンを表すように意図されている。特定の実装において、周期的アクティビティ・生成エンジン614は、識別されたアクティビティを形成するために、相互特徴相関およびグループ化を実行する。イベントは、デバイス、アプリケーション、ソースIP、送信ボリューム、等によってグループ化され得る。グループ化の目的は、関連するシグナルを見つけることである。従って、アクティビティは、関連するシグナルプラス（plus）コンテキストとして定義され得る(例えば、FTPログイン)。有利なことに、周期的アクティビティ・生成エンジン614は、アクティビティの周期性だけでなく、コンテキストの周期性も同様に検出することができる。
【００６７】
上述のように、周期的アクティビティは、異なる周期性を有するアクティビティを伴うセキュリティエージェントと関連付けられ得る。また、グループの行為をプロファイリング（profiling）することは、周期性の欠如グループのうち１つのIoTデバイスがグループ内の他ものとは異なる周期性を有する場合に、異常な周期性を見つけるのに役立つ。周期性の欠如(例えば、グループのうち９つのIoTデバイスが周期性を有しており、１０番目のIoTデバイスは有しておらず、それは、IoTデバイスの誤った分類、コンフィギュレーションの問題、悪意のあるアクティビティ、期待されるもの以外の何かを行うために別の目的で再利用されるIoTデバイス、等であってよく、結果として、異常な行為を示しているものとしてIoTデバイスが報告されることを生じている)、未知の周期性(例えば、IoTデバイスが、不正なインストール、悪意のあるソフトウェア、等を示す未知のドメインに対する３時間のメッセージの繰り返しパターンを有している)、または、周期性の変化(例えば、IoTデバイスが、日毎の代わりに毎日３回メッセージの送信を開始し、それは、コンフィグレーションの変化、アクティビティの変化（データがより頻繁に蓄積されているため、より頻繁にレポートする、といったもの）、自動インストールに応答していないパッチ／バージョンの変更、であってよく、ネットワークコンフィグレーションの失敗を示す、より頻繁なホームコールを行うように、そして、従って、より多くのホームコールを試みるように、マシンを移動している）、のせいであるか否かである。
【００６８】
特定の実装において、機械学習、そして、より特定の実装においては、クラスタリングが、シグナルをアクティビティへと変換するために使用される(例えば、クラスタリングを使用し、次いで、各グループをラベル付けする)。
【００６９】
特定の実装において、周期的アクティビティ・生成エンジン614は、他のIoTサービスアクティビティ(例えば、１つのアプリケーションは他のアプリケーションをトリガすることができる)といった、外部コンテキストと相関する。外部コンテキスト・データストア616は、例えば、ネットワーク環境(例えば、VLANセグメンテーション)パラメータ、アクティブスキャン結果(例えば、発見／脆弱性のリスト)、デバイスのパーソナリティ(例えば、OS、ファームウェア、ベンダ、識別子、タイプ、行為)、エンドポイント・ステータス(例えば、デバイス上で起きることを学習するためにAPIと統合されたシマンテック（Symantec）のエンドポイントソリューション)、レピュテーションインテル（reputation  intel）(例えば、IPアドレス・レピュテーション、ビジネス、AWS、エンターテイメント、等といったカテゴリ、デバイスタイプ、バージョン、等による脅威、及び／又は、公開されたデバイスの脆弱性または特性)、アプリケーションアクティビティ(例えば、関連イベントに関連するアプリケーションのアクティビティ)、ユーザ情報、等を含んでいる。これらのパラメータのいくつかは、代替的又は追加的(例えば、冗長的に)バックグラウンド・イベント・コンテキストとみなされる。外部コンテキスト・データストア616は、非アクティブ信号から抽出され得るデータを含むものとして特徴付けられ得る。コンテキスト・抽出エンジン620は、そうしたコンテキストを抽出するエンジンを表すように意図されている。特定の実装においては、コンテキスト抽出および信号生成が、並列に実行される。外部コンテキストは、各信号について異なってよく、それで、外部コンテキスト・データストア616は、概念的に異なる複数のデータストア616-1から616-nまでとして表されている。
【００７０】
特定の実装において、アクティビティ生成は、特徴および値の範囲のリストを含む(そして、分類子（classifier）として特徴付けられ得る)、アクティビティ定義の生成を必然的に伴う。生成されたアクティビティ記述子は、アクティビティID(または、周期性が検出された後に取得され、そして、一般的にはヒトのアドミニストレータの利益のために、ハンドルとして使用される、周期的アクティビティID)、多次元統合された特徴値、特徴値範囲(例えば、低い、平均、高い)、デバイスID、アプリケーションID、ユーザID(アクティビティをトリガした者)、サンプリングインターバル(例えば、５分、１時間、１日、等の既定の集約インターバル)、特徴クラス、特徴グループ、特徴優先度、そして、アクティビティ、タイムスタンプ、時間インターバル、および時間デルタを分類するために使用されるアルゴリズム、を含み、いくつかのパラメータを示すことができる。多次元手段は、周期性および多重相関周期性を識別するためのモデル内に複数の特徴が存在することを意味する。
【００７１】
異常周期的アクティビティ・IoTネットワーク・脅威評価エンジン120は、周期的アクティビティを経時的に追跡するエンジンを表すように意図されている。期待される周期的アクティビティが検出されない場合に、その欠落は異常であるとして扱われ、そして、異常周期的アクティビティ・IoTネットワーク・脅威評価エンジン120はアラートを生成する。外部コンテキストは、アラートが挙げられるか否かに影響を与え得る、ヒトまたは人工エージェントが脅威レベルを評価するのを支援することができる。悪意のある反復パターンおよび良性の反復パターンの両方を有することが可能である。(以前に定義されていない周期的アクティビティも、また、異常であるとみなされ得るが、以前に定義されていない周期的アクティビティを検出することは、周期的アクティビティ・生成エンジン116の機能の一部分とみなすことができ、これは、アクティビティを悪意のある又は良性のものとして定義することができる。)有利なことに、アクティビティ記述子を利用して、異常周期的アクティビティ・IoTネットワーク・脅威評価エンジン120は、周期的変動を検出するために、異常検出を使用することができる。動作において、異常周期的アクティビティ・IoTネットワーク・脅威評価エンジン120は、リップル（ripple）検出を実行する。それは、今までIoTネットワークにわたりリップル検出されていない周期的な行為を示すIoTデバイスに関連する構成的なハートビート（heartbeat）検出である。
【００７２】
図8は、一つの例示的なIoT周期的アクティビティ学習のための方法のフローチャート800を示している。この文書で説明されるフローチャート800および他のフローチャートは、適用可能であれば、シーケンシャルに記録され、または、並列シーケンスへと再構成され得るモジュールを有している。
【００７３】
フローチャート800は、モジュール802で開始され、そこでは、IoTイベント、少なくともその一部分が第１IoTデバイスおよび第１IoTアプリケーションに関連するもの、がキャプチャされる。特定の実装において、イベントは、受動的モニタリング（passive  monitoring）によって検出される。検出された離散イベントのかなり些細なタイプは、おそらく、第１IoTデバイスに対するメッセージ、または、第１IoTデバイスから第１IoTアプリケーション・コントローラへのメッセージである。パケットヘッダ内の情報といった、特徴付けのために比較的少ないリソースを必要とする個別のイベントを検出することに焦点を当てることが望ましいだろうが、ディープ・パケットインスペクション(DPI)といった、他のよりリソース集約的な技法が、より多くのイベントデータを獲得するために使用され得る。実装特有および他の考慮事項に依存して、IoTアプリケーション学習またはIoTアプリケーションアクティビティのオーケストレーション（orchestration）の目的のために後に使用されるイベントは、離散的なイベントだけ含み、または、含まなくてもよい。いずれにせよ、アクティビティはイベントのラベル付きコレクションである。離散イベントとは対照的に、集約されたイベントのかなり些細な例は、第１IoTデバイスによって周期的に送信され、かつ、単一の(集約された)イベントとして扱われる、ハートビートメッセージのコレクションである。しかしながら、集約されたイベントは、はるかに複雑であり、そして、第１IoTデバイス(または、第１IoTアプリケーション・コントローラ)に必ずしも関連付けられないであろうが、第１IoTアプリケーションとそれ以外の関係のないイベントとの間の相関が識別されたことを判定するために使用されるであろう、データを組み込むことさえできる。特定の実装において、離散イベントは、機械学習を使用して、集約イベントを形成するために集められる。共通要因集約（common  factor  aggregation）は、検出された行為およびモデル化された行為の両方に適用される共通要因(いくつか例を挙げると、Windowsを使用し、telnetを使用する、同じプロファイル、同じOSの全てのデバイス、特定のサブネットと通信する、全てのデバイス、等)に焦点を当てることによって、様々な異なる機械学習およびディープラーニングアルゴリズムを適用するための方法である。例えば、セッション・イベントが集約され得る。別の例においては、ストリーミング・イベントが集約され得る。イベントは、第１IoTアプリケーションに関してローカルに集約され得る。例えば、イベントは、第１IoTデバイスを伴うLANの一部分として実装されるデバイスによって集約イベントを形成するために集められ得る。ラベル付けされた集約イベントは、この文書において「アクティビティ（“activities”）」として参照され得るが、より一般的に、アクティビティは、１つ以上のイベントのラベル付けされたコレクションであり、これは離散的であり又は集約され得ることが、留意されるべきである。モジュール802は、図1のイベントキャプチャ・エンジン108といった、イベントキャプチャ・エンジンによって実行され得る。
【００７４】
フローチャート800はモジュール804へ続き、そこでは、IoT信号特徴がIoTイベントから生成され、そのうち少なくともいくらかは、第１IoTデバイスおよび第１IoTアプリケーションのアクティビティに関連する。１つ以上のIoTシグナル特徴は、第１IoTデバイスおよび第１IoTアプリケーションのシグネチャとして機能する（serve）ことができる。概念的に、アクティビティは、特徴及び／又は支配的なトレンドと共に、ストリーミング、ファイルアップロード、管理、等として特徴付けられ得る(例えば、防犯カメラアプリケーションについては、ストリーミングが支配的であり得る)。特定の実装において、アクティビティの領域（universe）は、比較的小さなセットへと抜き出される（distilled）(例えば、定義されたアクティビティは、ログイン、認証、アップデートリクエスト、ダウンロード、インストール、等といった、一般的にヒトが読むことができる１００個以下の集約されたイベントに制限され得る)。特定の実装において、複数の軽量エンジンは、複数のアクティビティそれぞれ(例えば、ダウンロード)、または、アクティビティの比較的に共通のサブセット(例えば、Windows(R)ダウンロード)に焦点を当てる。これらのアクティビティそれぞれは、それらに適用可能な一式の信号特徴を有する。モジュール804は、図1のIoT信号特徴・生成エンジン112といった、IoT信号特徴・生成エンジンによって実行され得る。
【００７５】
フローチャート800はモジュール806へ続き、そこでは、バックグラウンド・イベント・コンテキストがIoTイベントから抽出される。モジュール806は、図1のIoT信号特徴・生成エンジン112といった、IoT信号特徴・生成エンジンによって実行され得る。
【００７６】
フローチャート800はモジュール808へ続き、そこでは、IoT信号特徴およびバックグラウンド・イベント・コンテキストを使用して、周期的アクティビティ・インスタンス記述子が生成される。モジュール808は、図1の周期的アクティビティ・定義エンジン116といった、周期的アクティビティ・定義エンジンによって、または、図6の周期性・発見エンジン610といった、周期性・発見エンジンによって実行され得る。
【００７７】
フローチャート800はモジュール810へ続き、そこでは、外部コンテキストが非アクティブIoTイベントから抽出される。非アクティブIoTイベントとは、考慮中のIoTシグナルの一部分ではないイベントである。モジュール810は、図1の周期的アクティビティ・定義エンジン116といった、周期的アクティビティ・定義エンジンによって、または、図6のコンテキスト・抽出エンジン620といった、コンテキスト・抽出エンジンによって実行され得る。
【００７８】
フローチャート800はモジュール812へ続き、そこでは、周期的アクティビティ・インスタンス記述子および外部コンテキストを使用して、周期的アクティビティが定義される。モジュール812は、図1の周期的アクティビティ・定義エンジン116といった、周期的アクティビティ・定義エンジンによって、または、図6の周期的アクティビティ・生成エンジン614といった、周期的アクティビティ・生成エンジンによって実行され得る。
【００７９】
フローチャート800はモジュール814へ続き、そこでは、検出されたアクティビティが期待される周期性に対してマッチング（match）される。フローチャート800は、連続フローを表すように意図されており、そこでは、周期性を決定するために分析されるものと同じイベントが、また、期待される周期性に対してマッチングされる。しかしながら、周期性を決定するために使用される機械学習技法はオフラインで発生し得るものであり、一方、信号を既知の周期性にマッチングさせることはリアルタイムで発生し得ることに留意されたい。検出されたアクティビティが期待される周期性と一致しない場合には、期待される周期性が検出されなかったことを示すアラートが生成され得る。この失敗が１回から所与の回数まで発生する場合には、プリファレンスに応じて、期待される周期的アクティビティが停止したことを示すアラートが生成され得る。検出されたアクティビティは、また、既知の悪意ある周期的なアクティビティとマッチングされ、そして、一致する際にアラートが生成され得る。従って、「異常（“anomalous”）」は、期待される周期的イベントの欠如、または、ポリシーに違反する周期的イベントの存在を参照することができる。モジュール814は、異常周期的アクティビティ・IoTネットワーク・脅威評価エンジン120といった、異常周期的アクティビティ・IoTネットワーク・脅威評価エンジンによって実行され得る。
【００８０】
前述のテキストおよび図において説明される技法は、代替的な実装を生成するために、必要とされる状況に応じて、混合され、マッチングされ得る。
【図１】
2022502736.tif 000003
【図２】
2022502736.tif 000004
【図３】
2022502736.tif 000005
【図４】
2022502736.tif 000006
【図５】
2022502736.tif 000007
【図６】
2022502736.tif 000008
【図７】
2022502736.tif 000009
【図８】
2022502736.tif 000010
【国際調査報告】
2022502736.tif 000011