▶ パロ アルト ネットワークス，インコーポレイテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-11
(45)【発行日】2024-01-19
(54)【発明の名称】ＩｏＴデバイスの検出および識別
(51)【国際特許分類】
G06F 21/55 20130101AFI20240112BHJP
【ＦＩ】
G06F21/55
【請求項の数】
12
(21)【出願番号】P 2022565976
(86)(22)【出願日】2021-06-01
(65)【公表番号】
(43)【公表日】2023-06-09
(86)【国際出願番号】 US2021035278
(87)【国際公開番号】W WO2021247597
(87)【国際公開日】2021-12-09
【審査請求日】2022-10-28
(31)【優先権主張番号】63/033,004
(32)【優先日】2020-06-01
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/133,189
(32)【優先日】2020-12-23
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】517392861
【氏名又は名称】パロ アルト ネットワークス，インコーポレイテッド
【氏名又は名称原語表記】Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．
【住所又は居所原語表記】３０００ Ｔａｎｎｅｒｙ Ｗａｙ，Ｓａｎｔａ Ｃｌａｒａ，Ｃａｌｉｆｏｒｎｉａ ９５０５４，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ドゥ，ジュン
(72)【発明者】
【氏名】ザオ，イーリン
【審査官】青木 重徳
(56)【参考文献】
【文献】特表２０２０－５０３７８４（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１９／０３８７３９９（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１９／０２６８３０５（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１７／０１８０３８０（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１６／０３０１７１７（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１９／００１４１６９（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１１／００８７６２６（ＵＳ，Ａ１）
【文献】Michael Blackstock et al.，IoT Interoperabilty: A Hub-based Approach，2014 International Conference on the Internet of Things (IOT)，米国，IEEE，2014年10月06日，pp. 79-84
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ２１／５５
ＪＳＴＰｌｕｓ／ＪＭＥＤＰｌｕｓ／ＪＳＴ７５８０（ＪＤｒｅａｍＩＩＩ）
ＩＥＥＥ Ｘｐｌｏｒｅ
(57)【特許請求の範囲】
【請求項1】
プロセッサおよびメモリを含む、システムであって、前記プロセッサは、
IoTデバイスのネットワーク通信に関連する情報を受信し、
前記IoTデバイスが分類されているか否かを判断し、
前記IoTデバイスが分類されていないとの判断に応じて、２つの部分からなる分類プロセスを実行し、
前記分類プロセスの第１部分は、インライン分類を含み、
前記分類プロセスの第２部分は、前記インライン分類のその後の検証を含み、かつ、
前記IoTデバイスにポリシを適用するように構成されたセキュリティアプライアンスに対して、前記分類プロセスの結果を提供する、
ように構成されており、
前記メモリは、前記プロセッサに結合されており、かつ、前記プロセッサに命令を提供する、
システム。
【請求項2】
前記情報は、前記IoTデバイスをモニタリングするように構成されたデータアプライアンスから受信される、請求項１に記載のシステム。
【請求項3】
前記受信された情報は、ネットワークトラフィックメタデータを含む、請求項１に記載のシステム。
【請求項4】
前記分類プロセスの前記第１部分は、ルールベースの分類を含む、請求項1に記載のシステム。
【請求項5】
前記分類プロセスの前記第２部分は、機械学習ベースの分類を含む、請求項１に記載のシステム。
【請求項6】
前記分類プロセスを実行することは、前記IoTデバイスについていずれかの特徴が支配的であるか否かを決定すること、を含む、請求項１に記載のシステム。
【請求項7】
前記２つの部分からなる分類プロセスを実行することは、前記IoTデバイスの１つ以上の特徴がネットワーク挙動パターン識別子と一致することの信頼性を判断すること、を含む、請求項１に記載のシステム。
【請求項8】
前記プロセッサは、さらに、前記ネットワーク挙動パターン識別子を生成するように構成されている、請求項７に記載のシステム。
【請求項9】
前記分類プロセスの結果は、グループ分類を含む、請求項１に記載のシステム。
【請求項10】
前記分類プロセスの結果は、プロファイル分類を含む、請求項１に記載のシステム。
【請求項11】
IoTデバイスのネットワーク通信に関連する情報を受信するステップと、前記IoTデバイスが分類されているか否かを判断するステップと、
前記IoTデバイスが分類されていないとの判断に応じて、２つの部分からなる分類プロセスを実行するステップであり、
前記分類プロセスの第１部分は、インライン分類を含み、
前記分類プロセスの第２部分は、前記インライン分類のその後の検証を含む、
ステップと、
前記IoTデバイスにポリシを適用するように構成されたセキュリティアプライアンスに対して、前記分類プロセスの結果を提供するステップと、
を含む、方法。
【請求項12】
複数のコンピュータ命令を含み、有形のコンピュータ読取可能な記憶媒体に保管される、コンピュータプログラムであって、前記命令が実行されると、コンピュータに、
IoTデバイスのネットワーク通信に関連する情報を受信するステップと、
前記IoTデバイスが分類されているか否かを判断するステップと、
前記IoTデバイスが分類されていないとの判断に応じて、２つの部分からなる分類プロセスを実行するステップであり、
前記分類プロセスの第１部分は、インライン分類を含み、
前記分類プロセスの第２部分は、前記インライン分類のその後の検証を含む、
ステップと、
前記IoTデバイスにポリシを適用するように構成されたセキュリティアプライアンスに対して、前記分類プロセスの結果を提供するステップと、
を実施させる、
コンピュータプログラム。
【発明の詳細な説明】
【背景技術】
【0001】
悪意のある個人は、様々な方法でコンピュータシステムを侵害しようと試みる。一つの例として、そうした個人は、電子メール添付ファイルに悪意のあるソフトウェア(「マルウェア（“malware”）」)を埋め込み、または、他の方法で組み込み、かつ、送信し、もしくは、怪しまないユーザに対してマルウェアが送信されるようにし得る。実行されると、マルウェアは、被害者のコンピュータを危険にさらし、そして、追加の悪質なタスク(例えば、機密データを抽出する（exfiltrating）、他のシステムへ伝搬する、等)を実行することができる。そうした又は他の危険（compromise）妥協に対してコンピュータを強固にするために、様々なアプローチが使用され得る。残念ながら、コンピュータの保護に対する既存のアプローチは、必ずしも全てのコンピューティング環境に適しているとは限らない。さらに、マルウェアの作成者は、検出を回避するように自身のテクニックを頻繁に適応させており。そして、様々な状況において、マルウェアを検出し、かつ、その被害を防ぐための改善されたテクニックについて、現在進行形で必要性が存在している。
【0002】
他の出願に対する相互参照
本出願は、2020年6月1日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である米国仮特許出願第63/033004号について優先権を主張するものであり、全ての目的のために、参照により、ここにおいて組み込まれている。
本出願は、2020年6月1日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である米国仮特許出願第63/033004号について優先権を主張するものであり、全ての目的のために、参照により、ここにおいて組み込まれている。
【図面の簡単な説明】
【0003】
本発明の様々な実施形態が、以下の詳細な説明および添付の図面において開示されている。
【発明を実施するための形態】
【0004】
本発明は、プロセス、装置、システム、物質の組成、コンピュータ読取可能記憶媒体上に具現化されたコンピュータプログラム製品、及び／又は、プロセッサに結合されたメモリにより保管され、かつ／あるいは、提供される命令を実行するように構成されたプロセッサといったプロセッサを含む、多数の方法で実施することができる。本明細書において、これらの実施形態、または、本発明が採り得る任意の他の形態は、技術（technique）と称される。一般的に、開示されたプロセスのステップの順序は、本発明の範囲内で変更すされ得る。特に断らない限り、タスクを実行するように構成されているものとして説明されるプロセッサまたはメモリといったコンポーネントは、所与の時間にタスクを実行するように一時的に構成されている一般的なコンポーネント、または、タスクを実行するように製造されている所定のコンポーネントとして実装され得る。ここにおいて使用されるように、用語「プロセッサ（“processor”）」は、コンピュータプログラム命令といった、データを処理するように構成された１つ以上のデバイス、回路、及び／又は、処理コアを指す。
【0005】
本発明の１つ以上の実施形態に係る詳細な説明が、本発明の原理を説明する添付の図面と共に以下に提供される。本発明は、そうした実施形態に関連して説明されるが、本発明は、あらゆる実施形態に限定されるものではない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、そして、本発明は、多数の代替物、修正物、および均等物を含んでいる。本発明の完全な理解を提供するために、以下の説明において多数の具体的な詳細が明らかにされる。これらの詳細は、例示のために提供されており、そして、本発明は、これらの所定の詳細の一部または全部を伴うことなく、請求項に従って実施され得る。明確化の目的のため、発明に関連する技術分野において知られている技術的資料は、本発明が不必要に不明瞭にならないように、詳細には説明されていない。
【0006】
システムおよび方法について説明される。モノのインターネット（Internet of Things、IoT)デバイスのネットワーク通信に関連する情報が受信される。いくつかの態様において、情報は、IoTデバイスをモニタリングするように構成されたデータアプライアンスから受信される。いくつかの態様において、受信された情報は、ネットワークトラフィックメタデータを含んでいる。IoTデバイスが分類されていないとの判断に応答して、２つの部分からなる（two-part）分類プロセスが実行される。分類プロセスの第１部分は、インライン分類を含み、そして、分類プロセスの第２部分は、インライン分類のその後の検証を含んでいる。いくつかの態様において、分類の第１部分は、ルールベース（rule-based）の分類を含む。いくつかの態様において、分類プロセスの第２部分は、機械学習ベース（machine learning-based）の分類を含む。いくつかの態様において、分類プロセスを実行することは、IoTデバイスの任意の特徴が支配的であるか否かを決定することを含む。いくつかの態様において、２つの部分からなる分類プロセスを実行することは、IoTデバイスの１つ以上の特徴がネットワーク挙動パターン識別子と一致することの信頼性を判断することを含む。ネットワーク挙動パターン識別子は、システム／方法／コンピュータプログラム製品によって生成することができる。分類プロセスの結果は、IoTデバイスに対してポリシを適用するように構成されたセキュリティアプライアンスに提供される。いくつかの態様において、結果は、グループ分類を含んでいる。いくつかの態様において、結果は、プロファイル分類を含んでいる。
【0007】
Ｉ．概要
【0008】
ファイアウォールは、一般的に、認可された通信がファイアウォールを通過するのを許可しながら、不正アクセスからネットワークを保護している。ファイアウォールは、典型的に、デバイス、一連のデバイス、または、ネットワークアクセスのためのファイアウォール機能を提供するデバイス上で実行されるソフトウェアである。例えば、ファイアウォールは、デバイス(例えば、コンピュータ、スマートフォン、または、他のタイプのネットワーク通信可能デバイス)のオペレーティングシステムへと統合することができる。ファイアウォールは、また、コンピュータサーバ、ゲートウェイ、ネットワーク／ルーティングデバイス(例えば、ネットワークルータ)、および、データアプライアンス(例えば、セキュリティアプライアンスまたは他のタイプの特殊目的デバイス)といった、種々のタイプのデバイス上の１つ以上のソフトウェアアプリケーションに統合または実行することができ、そして、種々の実装において、所定の動作は、ASICまたはFPGAといった、特殊目的ハードウェアで実装することができる。
【0009】
ファイアウォールは、典型的に、一連のルールに基づいてネットワーク送信を拒否または許可する。これらの一連のルールは、しばしば、ポリシ(例えば、ネットワークポリシまたはネットワークセキュリティポリシ)と呼ばれる。例えば、ファイアウォールは、不要な外部トラフィックが保護されるデバイスに到達するのを防ぐために、一連のルールまたはポリシを適用することによって、インバウンド（inbound）トラフィックをフィルタリングすることができる。ファイアウォールは、また、一連のルールまたはポリシを適用することによってアウトバウンドトラフィックをフィルタリングすることもできる(例えば、許可、ブロック、モニタリング、通知、またはログ、及び／又は、ファイアウォールルールまたはファイアウォールポリシにおいて指定することができる他のアクションであり、ここにおいて説明されるように、様々な基準（criteria）に基づいてトリガすることができる)。ファイアウォールは、また、一連のルールまたはポリシを同様に適用することによって、ローカルネットワーク(例えば、イントラネット)トラフィックをフィルタリングすることもできる。
【0010】
セキュリティ装置(例えば、セキュリティアプライアンス、セキュリティゲートウェイ、セキュリティサービス、及び／又は、他のセキュリティ装置)は、様々なセキュリティ機能(例えば、ファイアウォール、マルウェア対策、侵入防止／検出、データ損失防止(Data Loss Prevention、DLP)、及び／又は、他のセキュリティ機能)、ネットワーク機能(例えば、ルーティング、クオリティオブサービス（Quality of Service、QoS)、ネットワーク関連リソースのワークロードバランシング、及び／又は、他のネットワーク機能)、及び／又は、他の機能を含み得る。例えば、ルーティング機能は、送信元情報(例えば、IPアドレスおよびポート)、宛先情報(例えば、IPアドレスおよびポート)、および、プロトコル情報に基づくことができる。
【0011】
基本的なパケットフィルタリングファイアウォールは、ネットワークを介して送信される個々のパケットを検査することによって、ネットワーク通信トラフィックをフィルタリングする(例えば、パケットフィルタリングファイアウォール、または、ステートレスパケットフィルタリングファイアウォールである、第１世代ファイアウォール)。ステートレスパケットフィルタリングファイアウォールは、典型的に、個々のパケット自体を検査し、そして、検査されたパケットに基づいてルールを適用する(例えば、パケットの送信元および宛先のアドレス情報、プロトコル情報、および、ポート番号の組み合わせを使用する)。
【0012】
アプリケーションファイアウォールは、また、アプリケーション層フィルタリング(例えば、アプリケーション層フィルタリングファイアウォール、または、TCP/IPスタックのアプリケーションレベル上で機能する、第２世代ファイアウォール)を実行することもできる。アプリケーション層フィルタリングファイアウォールまたはアプリケーションファイアウォールは、一般的に、所定のアプリケーションおよびプロトコルを識別することができる(例えば、ハイパーテキスト転送プロトコル(HTTP)、ドメインネームシステム(DNS)要求、ファイル転送プロトコル(FTP)を使用するファイル転送、並びに、Telnet、DHCP、TCP、UDP、およびTFTP(GSS)といった、他の様々なタイプのアプリケーションおよび他のプロトコル、を使用するウェブブラウジング)。例えば、アプリケーションファイアウォールは、標準ポートを介して通信を試みる未認可プロトコルをブロックすることができる(例えば、そのプロトコルについて非標準ポートを使用してスニーク（sneak）を試みる未認可／ポリシ外のプロトコルは、一般的に、アプリケーションファイアウォールを使用して識別され得る)。
【0013】
ステートフルファイアウォールは、また、状態ベース（state-based）のパケット検査を実行することができ、そこでは、各パケットが、そのネットワーク送信のパケットフローに関連する一連のパケットのコンテキスト内で検査される。このファイアウォール技術は、一般的に、ステートフルパケット検査と呼ばれる。ファイアウォールを通過する全ての接続の記録を保持し、かつ、パケットが新しい接続の開始であるか、既存の接続の一部であるか、または、無効なパケットであるかを判断できるからである。例えば、接続の状態自体は、ポリシ内のルールをトリガする基準の１つになり得る。
【0014】
先進または次世代ファイアウォールは、上述のように、ステートレスおよびステートフルパケットフィルタリング、および、アプリケーション層フィルタリングを実行することができる。次世代ファイアウォールは、また、追加のファイアウォール技術を実行することもできる。例えば、高度または次世代ファイアウォとして、ときどき、呼ばれる、所定の新しいファイアウォールは、また、ユーザおよびコンテンツを識別することもできる(例えば、次世代ファイアウォール)。特に、所定の次世代ファイアウォールは、アプリケーションのリストを拡大しており、これらのファイアウォールは自動的に何千ものアプリケーションを識別できる。そうした次世代ファイアウォールの例は、Palo Alto Networks社から市販されている(例えば、Palo Alto Networks社のPAシリーズファイアウォール)。例えば、Palo Alto Networks社の次世代ファイアウォールは、様々な識別技術を使用して、企業が、アプリケーション、ユーザ、およびコンテンツ－単に、ポート、IPアドレス、パケットだけではない－を識別し、かつ、制御するのを可能にする。正確なアプリケーション識別のためのAPP-ID、ユーザ識別のためのユーザID(例えば、ユーザまたはユーザグループによるもの)、および、リアルタイムのコンテンツスキャニングのためのコンテンツID(例えば、ウェブサーフィンの制御、および、データとファイルの転送の制限)、といったものである。これらの識別技術により、企業は、従来のポートブロッキングファイアウォールによって提供される従来のアプローチに従う代わりに、ビジネス関連のコンセプトを使用してアプリケーションの使用を安全に可能にすることができる。また、次世代ファイアウォールのための専用ハードウェア(例えば、専用アプライアンスとして実装されるもの)は、一般的に、汎用ハードウェア上で実行されるソフトウェアよりも、アプリケーション検査についてより高いパフォーマンスレベルを提供する(例えば、Palo Alto Networks社により提供されるセキュリティアプライアンスといったものであり、シングルパスソフトウェアエンジンと緊密に統合された、専用の、機能固有の処理を使用して、ネットワークスループットを最大化し、一方で、待ち時間を最小化する)。
【0015】
先進または次世代ファイアウォールは、また、仮想化ファイアウォールを使用して実装することもできる。そうした次世代ファイアウォールの例は、Palo Alto Networks社から市販されている(例えば、様々な商用仮想化環境をサポートする、Palo Alto Networks社のVMシリーズファイアウォールであり、例えば、VMware(R) ESXiTMおよびNSXTM、Citrix(R) Netscaler SDXTM、KVM/OpenStack(Centos/RHEL、Ubuntu(R))、および、Amazon Web Services(AWS)を含んでいる)。例えば、仮想化ファイアウォールは、物理的フォームファクタアプライアンスで利用可能な、次世代ファイアウォールおよび先進脅威防止機能と類似し、または完全に同一のものをサポートすることができ、企業は、プライベート、パブリック、およびハイブリッドのクラウドコンピューティング環境の中で、かつ、横切るアプリケーションのフローを安全に可能にすることができる。VMモニタリング、ダイナミックアドレスグループ、RESTベースのAPIといった自動化機能により、企業は、VMの変化を積極的にモニタリングすることができ、そのコンテキストをセキュリティポリシの中へ動的にフィードし、それにより、VMの変化時に生じ得るポリシの遅れ（lag）を排除している。
【0016】
ＩＩ．例示的な環境
【0017】
図1は、悪意のあるアクティビティが検出され、そして、その被害が低減される環境に係る一つの例を示している。図1に示される例において、クライアント装置104-108は、病院(「アクメ病院（“Acme Hospital”）」とも呼ばれる)のエンタープライズネットワーク110内に存在する、ラップトップコンピュータ、デスクトップコンピュータ、および、タブレットである。データアプライアンス102は、クライアントデバイス104と106といった、クライアントデバイスと、エンタープライズネットワーク110外のノード(例えば、外部ネットワーク118を介して到達可能なもの)との間の通信に関するポリシを実施するように構成されている。
【0018】
そうしたポリシの例は、トラフィックシェーピング（shaping）、クオリティオブサービス、およびトラフィックのルーティングを管理するものを含んでいる。ポリシの他の例は、受信（及び／又は、送信）電子メールの添付ファイル、ウェブサイトのコンテンツ、インスタントメッセージングプログラムを介して交換されるファイル、及び／又は、他のファイル転送における脅威についてスキャンを要求するもの、といった、セキュリティポリシを含んでいる。いくつかの実施形態において、データアプライアンス102は、また、エンタープライズネットワーク110内に留まるトラフィックに関してポリシを実施するようにも構成されている。
【0019】
ネットワーク110は、また、ディレクトリサービス154、および、認証、認可、および課金サーバ（Authentication, Authorization, and Accounting、AAA）156も含んでいる。図1に示される例において、ディレクトリサービス154(識別プロバイダまたはドメインコントローラとも呼ばれるもの)は、ライトウェイトディレクトリアクセスプロトコル（Lightweight Directory Access Protocol、LDAP）または他の適切なプロトコルを使用する。ディレクトリサービス154は、ユーザ識別情報およびクレデンシャル情報を管理するように構成されている。ディレクトリサービス154の一つの例は、Microsoft Active Directoryサーバである。他のタイプのシステムも、また、ケルベロスベース（Kerberos-based）システムといった、Active Directoryサーバの代わりに、を使用することもでき、そして、ここにおいて説明されているテクニックが、それに応じて適用される。図1に示される例において、AAAサーバ156は、ネットワーク・アドミッション・コントロール（NAC）サーバである。AAAサーバ156は、ネットワークへのアクセスを許可する前に、ネットワークに対する有線、無線、およびVPNユーザと装置とを認証し、ポリシ遵守のために装置を評価および修正し、役割に基づいてアクセスを区別し、そして、次いで、ネットワーク上の誰がいるかを監査および報告するように構成されている。AAAサーバ156の一つの例は、リモート認証ダイヤルインユーザサービス（Remote Authentication Dial-In User Service、RADIUS）を利用するCisco Identity Services Engineサーバである。RADIUS以外のプロトコルを使用するものを含む、他のタイプのAAAサーバが、ここにおいて説明された技術と共に使用され得る。
【0020】
様々な実施形態において、データアプライアンス102は、ディレクトリサービス154及び／又はAAAサーバ156への／からの通信を聞く(例えば、受動的にメッセージをモニタリングする)ように構成されている。様々な実施形態において、データアプライアンス102は、ディレクトリサービス154及び／又はAAAサーバ156と通信する(すなわち、積極的にメッセージを通信する)ように構成されている。様々な実施形態において、データアプライアンス102は、ディレクトリサービス154及び／又はAAAサーバ156といった様々なネットワーク要素と通信する(例えば、積極的にメッセージを通信する)オーケストレータ(図示せず)と通信するように構成されている。他のタイプのサーバも、また、ネットワーク110に含めることができ、かつ、データアプライアンス102と適宜通信することができ、そして、ディレクトリサービス154及び／又はAAAサーバ156は、また、様々な実施形態においてネットワーク110から省略することもできる。
【0021】
図1では単一のデータアプライアンス102を有するものとして示されているが、所与のネットワーク環境(例えば、ネットワーク110)は、個別に、または、協調して動作するかいずれかの、データアプライアンスの複数の実施形態を含むことができる。同様に、用語「ネットワーク（“network”）」は、一般的に、ここにおいては単純化のために単数形(例えば、「ネットワーク110」)で言及されているが、ここにおいて説明される技術は、適用できる場合、様々なネットワーク層にわたり、様々なネットワークプロトコル(例えば、TCPとUDP)およびインフラストラクチャ(例えば、スイッチとルータ)を使用して、ネットワーク技術の様々なミックス（例えば、仮想化と物理的）を含む、様々なサイズおよびトポロジーの様々なネットワーク環境において展開することができる。
【0022】
データアプライアンス102は、リモートセキュリティプラットフォーム140と協働して動作するように構成することができる。セキュリティプラットフォーム140は、マルウェアサンプルについて(例えば、サンプル分析モジュール124を介して)静的および動的分析を実行すること、および、既知の悪意のあるファイル、ドメイン、等の署名のリストを、サブスクリプションの一部として、データアプライアンス102といった、データアプライアンスに対して提供すること、を含む、様々なサービスを提供することができる。以下で、より詳細に説明されるように、セキュリティプラットフォーム140は、また、ネットワーク110といったネットワーク内に存在するIoTデバイスの発見、分類、管理、等に関連する情報を(例えば、IoTモジュール138を介して)提供することもできる。様々な実施形態において、署名、分析の結果、及び／又は、追加情報(例えば、サンプル、アプリケーション、ドメイン、等に関するもの)がデータベース160内に保管される。様々な実施形態において、セキュリティプラットフォーム140は、典型的なサーバクラスのオペレーティングシステム(例えば、Linux（登録商標）)を実行する１つ以上の専用の市販されているハードウェアサーバ(例えば、マルチコアプロセッサ、32G+のRAM、ギガビットネットワークインターフェイスアダプタ、およびハードドライブを有しているもの)を含む。セキュリティプラットフォーム140は、複数のそうしたサーバ、ソリッドステートドライブ、または、他のストレージ装置158、及び／又は、他の適用可能な高性能ハードウェアを含む、スケーラブルインフラストラクチャにわたり実装することができる。セキュリティプラットフォーム140は、１つ以上の第三者によって提供されるコンポーネントを含む、いくつかの分散コンポーネントを有することができる。例えば、セキュリティプラットフォーム140の一部または全部は、Amazon Elastic Compute Cloud（EC2）、及び／又は、Amazon Simple Storage Service（S3）を使用して実装することができる。さらに、データアプライアンス102と同様に、セキュリティプラットフォーム140が、データ保管またはデータ処理といった、タスクを実行するものとして称されるときはいつでも、セキュリティプラットフォーム140のサブコンポーネントまたは複数のサブコンポーネントは(個別に、または、第三者コンポーネントと協力して、のいずれかで)、そのタスクを実行するために協働し得ることが理解されるべきである。例として、セキュリティプラットフォーム140は、１つ以上の仮想マシン(VM)サーバと協力して、(例えば、サンプル分析モジュール124を介して)静的／動的分析、及び／又は、(例えば、IoTモジュール138を介して)IoTデバイス機能を実行することができる。仮想マシンサーバの一つの例は、VMware ESXi、Citrix XenServer、またはMicrosoft Hyper-Vといった、市販されている仮想化ソフトウェアを実行する、市販され利用可能であるサーバクラスのハードウェア(例えば、マルチコアプロセッサ、32+ギガバイトのRAM、および、１つ以上のギガビットネットワークインターフェイスアダプタ)を含む物理マシンである。いくつかの実施形態において、仮想マシンサーバは省略されている。さらに、仮想マシンサーバは、セキュリティプラットフォーム140を管理する同じエンティティの制御下にあってよいが、また、第三者によって提供されてもよい。一つの例として、仮想マシンサーバは、EC2に依存することができ、セキュリティプラットフォーム140の残りの部分は、セキュリティプラットフォーム140のオペレータによって所有され、かつ、制御下にある専用ハードウェアによって提供される。
【0023】
データアプライアンスの一つの実施形態が図2Aに示されている。示される例は、種々の実施形態において、データアプライアンス102内に含まれる物理的コンポーネントの表現である。具体的に、データアプライアンス102は、高性能マルチコア中央処理装置（CPU）202およびランダムアクセスメモリ（RAM）204を含んでいる。データアプライアンス102は、また、ストレージ装置210(１つ以上のハードディスクまたはソリッドステートストレージ、といったもの)も含んでいる。様々な実施形態において、データアプライアンス102は、エンタープライズネットワーク110のモニタリング、および、開示された技術の実施において使用される情報を(RAM 204、ストレージ装置210、及び／又は、他の適切な場所のいずれかに)保管する。そうした情報の例は、アプリケーション識別子、コンテンツ識別子、ユーザ識別子、要求されたURL、IPアドレスマッピング、ポリシおよび他の設定情報、署名、ホスト名／URL分類情報、マルウェアプロファイル、機械学習モデル、IoTデバイス分類情報、等を含んでいる。データアプライアンス102は、また、１つ以上の任意的なハードウェアアクセラレータも含むことができる。例えば、データアプライアンス102は、暗号化および復号動作を実行するように構成された暗号エンジン206、および、マッチングを実行し、ネットワークプロセッサとして動作し、かつ／あるいは、他のタスクを実行するように構成された１つ以上のフィールドプログラマブルゲートアレイ（FPGA）208を含むことができる。
【0024】
データアプライアンス102によって実行されるものとしてここにおいて説明される機能性は、種々の方法で提供／実装することができる。例えば、データアプライアンス102は、専用デバイスまたはデバイスセットであってよい。所与のネットワーク環境は、複数のデータアプライアンスを含んでよく、それぞれは、ネットワークの特定の部分に対してサービスを提供するように構成することができ、ネットワークの特定の部分に対してサービスを提供するように協働することができる。データアプライアンス102によって提供される機能性は、汎用コンピュータ、コンピュータサーバ、ゲートウェイ、及び／又は、ネットワーク／ルーティングデバイス上のソフトウェアに統合され、または、実行することもできる。いくつかの実施形態において、データアプライアンス102によって提供されるものと説明される少なくともいくつかの機能性は、クライアント装置上で実行するソフトウェアによって、クライアント装置(例えば、クライアント装置104またはクライアント装置106)に対して、その代わりに(または、それに加えて)提供される。データアプライアンス102によって実行されるものとしてここにおいて説明される機能性は、また、セキュリティプラットフォーム140によって、または、協働して、少なくとも部分的に実行することもでき、かつ／あるいは、セキュリティプラットフォーム140によって実行されるものとしてここにおいて説明される機能性は、また、データアプライアンス102によって、または、適用できる場合、データアプライアンス102によって、または、協働して、少なくとも部分的に実行することもできる。一つの例として、IoTモジュール138によって実行されるものとして説明される種々の機能は、IoTサーバ134の実施形態によって実行され得る。
【0025】
データアプライアンス102がタスクを実行するものとして説明されるときはいつでも、単一のコンポーネント、コンポーネントのサブセット、または、データアプライアンス102の全てのコンポーネントは、タスクを実行するために協働し得る。同様に、データアプライアンス102のコンポーネントがタスクを実行するものとして説明されるときはいつでも、サブコンポーネントは、タスクを実行することができ、かつ／あるいは、コンポーネントは、他のコンポーネントと共にタスクを実行し得る。様々な実施形態において、データアプライアンス102の部分は、１つ以上の第三者によって提供されている。データアプライアンス102に利用可能な計算リソースの量といった要因に応じて、データアプライアンス102の様々な論理コンポーネント及び／又は特徴は、省略されてよく、そして、ここにおいて説明される技術は、それに応じて適合され得る。同様に、追加の論理コンポーネント／機能は、適用できる場合に、データアプライアンス102の実施形態において含めることができる。種々の実施形態におけるデータアプライアンス102に含まれるコンポーネントの一つの例は、アプリケーションを識別するように構成されているアプリケーション識別エンジンである(例えば、パケットフロー分析に基づいて、アプリケーションを識別するために種々のアプリケーションシグネチャを使用している)。例えば、アプリケーション識別エンジンは、セッションが関与するトラフィックのタイプが何か、決定することができる。Webブラウジング－ソーシャルネットワーキング、Webブラウジング－ニュース、SSH、等といったものである。様々な実施形態におけるデータアプライアンス102に含まれるコンポーネントの別の例は、以下で、より詳細に説明されるIoTサーバ134である。IoTサーバ134は、物理的であるか仮想化されているかいずれかで、スタンドアロンサーバ(または、サーバのセット)としての形態を含む、様々な形態をとることができ、そして、また、適用できる場合(例えば、図1に示すように)データアプライアンス102と共配置／組み込むこともできる。
【0026】
図2Bは、データアプライアンスの一つの実施形態の論理コンポーネントに係る機能ダイアグラムである。示された例は、種々の実施形態において、データアプライアンス102に含まれ得る論理コンポーネントの表現である。別段の規定がない限り、データアプライアンス102の種々の論理コンポーネントは、一般的に、１つ以上のスクリプトのセット(例えば、適用できる場合、Java、python、等で書かれたもの)を含む、種々の方法で実装可能である。
【0027】
示されるように、データアプライアンス102は、ファイアウォールを含み、そして、管理プレーン212およびデータプレーン214を含む。管理プレーンは、ユーザインタラクションの管理を担当する。ポリシの設定およびログデータの閲覧のためのユーザインターフェイスを提供することによる、といったものである。データプレーンは、データ管理を担当する。パケット処理およびセッション処理を実行することによる、といったものである。
【0028】
ネットワークプロセッサ216は、クライアント装置108といった、クライアント装置からパケットを受信し、そして、処理のためにそれらをデータプレーン214に提供するように構成されている。フローモジュール218は、新しいセッションの一部としてパケットを識別するときはいつでも、新しいセッションフローを生成する。その後のパケットは、フロールックアップに基づいて、そのセッションに属しているものとして識別される。適用できる場合、SSL復号エンジン220によってSSL復号が適用される。そうでなければ、SSL復号エンジン220による処理は省略される。復号エンジン220は、データアプライアンス102がSSL/TLSおよびSSHの暗号化トラフィックを検査および制御するのを助け、そして、従って、そうでなければ暗号化トラフィックに隠されたままであり得る脅威を停止するのを助けることができる。復号エンジン220は、また、エンタープライズネットワーク110から離れていく機密性の高いコンテンツを防止することを助けることもできる。復号は、URLカテゴリ、トラフィック送信元、トラフィック宛先、ユーザ、ユーザグループ、およびポートといった、パラメータに基づいて選択的に制御することができる(例えば、イネーブルされ、または、ディセーブルされる)。復号ポリシ(例えば、どのセッションを復号するか指定するもの)に加えて、復号プロファイルは、ポリシによって制御されるセッションについて様々なオプションを制御するように割り当てることができる。例えば、特定の暗号スイート（cipher suites）および暗号化プロトコルバージョンの使用が要求され得る。
【0029】
アプリケーション識別(APP-ID)エンジン222は、セッションが関与するトラフィックのタイプが何かを決定するように構成されている。一つの例として、アプリケーション識別エンジン222は、受信データにおけるGET要求を認識し、そして、セッションがHTTPデコーダを必要としていと結論付けることができる。場合によっては、例えば、ウェブブラウジングセッションにおいて、識別されたアプリケーションは変更可能であり、そして、そうした変更は、データアプライアンス102によって記録される。例えば、ユーザは、最初に、企業のWiki(訪問したURLに基づいて「Webブラウジング－生産性（“Web Browsing-Productivity”）」として分類されるもの)をブラウジングし、そして、次いで、ソーシャルネットワーキングサイト(訪問したURLに基づいて「Webブラウジング－ソーシャルネットワーキング（“Web Browsing-Social Networking”）」として分類されるもの)を続いてブラウジングすることができる。異なるタイプのプロトコルは、対応するデコーダを有している。
【0030】
アプリケーション識別エンジン222によって行われた決定に基づいて、パケットは、脅威エンジン224によって、パケット（順序が狂って受信され得るもの）を正しい順序に組み立て、トークン化を実行し、そして、情報を抽出するように構成された適切なデコーダに対して送信される。脅威エンジン224は、また、パケットに何が起こるべきかを決定するために、署名マッチングも実行する。必要に応じて、SSL暗号エンジン226は、復号されたデータを再暗号化することができる。パケットは、(例えば、宛先への)送信のために転送モジュール228を使用して転送される。
【0031】
図2Bにも示されるように、ポリシ232は、受信され、そして、管理プレーン212において保管される。ポリシは、ドメイン名、及び／又は、ホスト／サーバ名を使用して指定することができる、１つ以上のルールを含むことができ、そして、ルールは、１つ以上の署名、または、他のマッチング基準またはヒューリスティック（heuristics）を適用することができる。モニタリングされたセッショントラフィックフローから抽出された様々なパラメータ／情報に基づいて、加入者／IPフローについてセキュリティポリシを実施するため、といったものである。インターフェイス（I/F）通信器230は、(例えば、(REST)API、メッセージ、もしくは、ネットワークプロトコル通信または他の通信メカニズムを介して)通信管理のために提供される。ポリシ232は、また、IoTデバイスを含む通信を管理するためのポリシを含むこともできる。
【0032】
ＩＩＩ．IoTデバイスの発見および識別
【0033】
図1に戻って、悪意のある個人が(例えば、システム120を使用して)マルウェア130を作成したと仮定する。悪意のある個人は、脆弱なクライアント装置がマルウェア130のコピーを実行し、クライアント装置を危険にさらし、そして、クライアント装置をボットネットにおけるボット（bot）にすることを望んでいる。危険にさらされたクライアント装置は、次いで、タスクを実行し(例えば、暗号通貨のマイニング、サービス妨害攻撃への参加、および、他の脆弱なクライアント装置への伝搬)、そして、情報を報告するように、もしくは、そうでなければ、外部エンティティ(例えば、命令及び制御（C&C）サーバ150)についてデータを密かに抽出し（exfiltrate）、同様に、適用できる場合、C&Cサーバ150からの指示を受信するように、指示され得る。
【0034】
図1に示されているいくつかのクライアントデバイスは、エンタープライズ組織の中で典型的に使用されるコモディティコンピューティングデバイスである。例えば、クライアントデバイス104、106、および108は、それぞれ、典型的なオペレーティングシステム(例えば、macOS、Windows、Linux、Android、等)を実行する。そうしたコモディティコンピューティングデバイスは、しばしば、管理者によって、(例えば、会社発行のラップトップ、デスクトップ、および、タブレットとして、それぞれに)準備され、かつ、維持されており、そして、しばしば、ユーザアカウント(例えば、ユーザIDおよびクレデンシャル情報で構成されたディレクトリサービスプロバイダ(ドメインコントローラとも呼ばれる)によって管理されるもの)と共に運用される。一つの例として、従業員Aliceにラップトップ104が発行されてよく、彼女は、ACME関連の電子メールにアクセスし、そして、様々なACME関連のタスクを実行するために使用する。他のタイプのクライアントデバイス(ここでは、一般的に、モノのインターネットまたはIoTデバイスと呼ばれるもの)も、また、ますますネットワークに存在し、そして、しばしば、IT部門によって「管理されてない（“unmanaged”）」。そうした装置のいくつか(例えば、テレビ会議装置)は、様々な異なる種類の企業にわたり見出され得る(例えば、IoTホワイトボード144および146)。そうしたデバイスは、また、垂直に特定的であり得る。例えば、輸液ポンプ（infusion pump）およびコンピュータ断層撮影スキャナ(例えば、CTスキャナ112)は、ヘルスケアエンタープライズネットワーク(例えば、ネットワーク110)内で見出され得る例示的なIoTデバイスであり、そして、ロボットアームは、製造エンタープライズネットワーク内で見出され得る一つの例示的な装置である。さらに、消費者指向のIoTデバイス(例えば、カメラ)も、また、エンタープライズネットワーク内に存在し得る。コモディティコンピューティングデバイスと同様に、ネットワーク内に存在するIoTデバイスは、そうしたネットワークの内部または外部にある(または、適用できる場合は、両方)のリソースと通信することができる。
【0035】
コモディティコンピューティングデバイスと同様に、IoTデバイスは、不正な個人のターゲットである。残念ながら、ネットワークにおけるIoTデバイスの存在は、いくつかのユニークなセキュリティ／管理の課題を提起し得る。IoTデバイスは、しばしば、低消費電力デバイスまたは特殊目的デバイスであり、そして、しばしば、ネットワーク管理者が知ることなく配備される。そうした管理者に知られている場合でさえ、IoTデバイスにエンドポイント保護ソフトウェアまたはエージェントをインストールすることができない可能性がある。IoTデバイスは、専有の(または、そうでなければ非標準の)プロトコルを使用して、第三者のクラウドインフラストラクチャ(例えば、クラウドインフラストラクチャ126と直接通信する工業用温度計152)で管理され、そして、単独で／直接的に通信することができる。このことは、デバイスに対する脅威または攻撃がいつ起きているかに関して決定するために、そうしたデバイスに出入りするネットワークトラフィックをモニタリングする試みを混乱させ得る。さらに、いくつかのIoTデバイス(例えば、医療環境におけるもの)は、ミッションクリティカルである(例えば、ネットワーク接続された外科システム)。残念ながら、IoTデバイスが危険にさらされること(例えば、マルウェア130によるもの)、または、IoTデバイスに関連するトラフィックに対するセキュリティポリシの誤適用は、破滅的な影響を与える可能性がある。ここにおいて説明される技術を使用して、IoTデバイスを含む異種ネットワークのセキュリティを改善することができ、そして、そうしたネットワークにもたらされる危害を低減することができる。
【0036】
様々な実施形態において、データアプライアンス102は、IoTサーバ134を含んでいる。IoTサーバ134は、いくつかの実施形態において、セキュリティプラットフォーム140のIoTモジュール138と協力して、ネットワーク(例えば、ネットワーク110)内のIoTデバイスを識別するように構成されている。そうした識別は、例えば、データアプライアンス102によって、IoTデバイスに関連するトラフィックに関するポリシの作成および実施を助け、そして、ネットワーク110の他のエレメントの機能性を高める(例えば、AAA 156にコンテキスト情報を提供する)ために使用することができる。様々な実施形態において、IoTサーバ134は、受動的にトラフィックを嗅ぎ付け（sniff）／モニタリングするように構成された１つ以上のネットワークセンサを組み込んでいる。そうしたネットワークセンサ機能を提供する一つの例示的な方法は、タップインターフェイス（tap interface）またはスイッチミラーポート（switch mirror port）としてのものである。トラフィックをモニターする他のアプローチも、また、適用できる場合に、(追加的または代替的に)使用することができる。
【0037】
様々な実施形態において、IoTサーバ134は、(例えば、フロントエンド142を介して)IoTモジュール138に、ログまたは他のデータ(例えば、受動的にモニタリングしているネットワーク110から収集されるもの)を提供するように構成されている。図2Cは、IoTサーバとIoTモジュールとの間の一つの例示的なイベントパスを示している。IoTサーバ134は、デバイス発見イベントおよびセッションイベントをIoTモジュール138へ送信する。例示的な発見イベントおよびセッションイベントが、それぞれ、図2Dおよび図2Eに示されている。様々な実施形態において、デバイスを一意的に識別し、または、デバイスの識別を確認することができるパケットが観察されるときはいつでも(例えば、DHCP、UPNP、またはSMBパケットが観察される時はいつでも)、IoTサーバ134によって発見イベントが送信される。デバイスが(デバイスのネットワーク内外を問わず、他のノードと共に)有する各セッションは、セッションに関する情報(例えば、送信元／宛先情報、受信／送信されたパケット数、等)を要約するセッションイベント内で記述される。適用できる場合、複数のセッションイベントは、IoTモジュール138へ送信する前に、IoTサーバ134によって一緒にバッチされ得る。図2Eに示される例においては、２つのセッションが含まれている。IoTモジュール138は、デバイス評決イベント(234)を介してデバイス分類情報をIoTサーバ134に提供する。
【0038】
IoTモジュール138を実装する一つの例は、マイクロサービスベースのアーキテクチャを使用することである。IoTモジュール138は、また、適用できる場合、異なるプログラミング言語、データベース、ハードウェア、およびソフトウェア環境を使用して、かつ／あるいは、メッセージングを可能にし、コンテキストによって制限され、自律的に開発され、独立して展開可能であり、分散化され、かつ、構築されて、自動化されたプロセスである、サービスとして実装することもできる。IoTモジュール138によって実行される１つのタスクは、IoTサーバ134によって提供される(および、データアプライアンス136および148といったデータアプライアンスの他の実施形態によって提供される)データ内のIoTデバイスを識別し、そして、これらの装置に関する追加のコンテキスト情報を提供する(例えば、それぞれのデータアプライアンスに戻す)ことである。
【0039】
図2Fは、IoTモジュールの実施形態を示している。領域294は、全テナントのデータ全体にわたり、間隔(例えば、5分毎、1時間毎、および1日毎)で実行されるスパークアプリケーション（Spark Application）のセットを示している。領域296は、カフカ（Kafka）メッセージバスを示している。IoTモジュール138によって(例えば、IoTサーバ134から)受信されたセッションイベントメッセージは、IoTサーバ134で観測される際に、(例えば、帯域幅を保存するために)複数のイベントを一緒にバンドルする。変換モジュール236は、受信したセッションイベントを個々のイベントへと平坦化し、そして、250においてそれらをパブリッシュするように構成されている。平坦化されたイベントは、様々な異なる集約ルールを使用して集約モジュール238によって集約される。一つの例示的なルールは、「時間間隔(例えば、5分間)について、特定のデバイス及びそれが使用する各(APP-ID)アプリケーションについて全てのイベントデータを集約する」ことである。別の例示的なルールは、「時間間隔(例えば、1時間)について、特定の宛先IPアドレスと通信する特定のデバイスについて全てのイベントデータを集約する」ことである。各ルールについて、集約エンジン238は、集約されることを要する属性のリスト(例えば、デバイスによって使用されるアプリケーションのリスト、または、宛先IPアドレスのリスト)を追跡する。特徴抽出モジュール240は、属性から特徴を抽出する(252)。分析モジュール242は、装置分類を実行するために抽出された特徴を使用し(例えば、教師あり学習および教師なし学習を使用する)、その結果(254)は、(例えば、操作インテリジェンスモジュール244、脅威分析モジュール246、および異常検出モジュール248を介して)他のタイプの分析にパワー供給するために使用される。操作インテリジェンスモジュール244は、OTフレームワークおよび動作的（operational）またはビジネスインテリジェンスに関連する分析を提供する。アラート(256)が、分析の結果に基づいて生成できる。様々な実施形態において、モンゴデータベース（Mongo DB）258は、集約されたデータおよび特徴値を保管するために使用される。バックグラウンドサービス262は、スパークアプリケーションによって集約されたデータを受信し、そして、データをモンゴデータベース258に書き込む。APIサーバ260は、フロントエンド142から受信したリクエストを処理するために、モンゴデータベース258からデータを取り出してマージする。
【0040】
図2Gは、IoTデバイス識別分析を(例えば、分析モジュール242および関連要素の実施形態としてのIoTモジュール138内に)実装する例示的な方法を示している。発見イベントおよびセッションイベントは(例えば、図2Dおよび図2Eに、それぞれ、示されるように)、カフカトピックとしてメッセージバス上で生データ264として受信され(そして、また、ストレージ装置158にも保管される)。特徴は、特徴エンジン276によって抽出される(例えば、Spark/MapReducerを使用して実施することができる)。生データは、(例えば、送信元／宛先アドレスの)地理位置情報といった、追加のコンテキスト情報が、セキュリティプラットフォーム140によって、豊富化されている(266)。メタデータ特徴抽出(268)の最中に、時間間隔内にIPアドレスから送信されるパケットの数、時間間隔内に特定のデバイスによって使用されるアプリケーションの数、および、時間間隔内にデバイスによってコンタクトされるIPアドレスの数、といった特徴が構築される。特徴は、リアルタイムでインライン分析エンジン272に(例えば、JSONフォーマットで)渡され、そして、(例えば、オフラインモデリング299の最中に)後続のクエリのために(例えば、Apache Parquet/DataFrameといった適切なフォーマットで、特徴データベース270内に)保管される、の両方である。
【0041】
メタデータから構築される機能に加えて、第２タイプの機能が、IoTモジュール138によって構築され得る(274)。ここにおいては、分析機能と称されている。一つの例示的な分析機能は、集計データを使用して、時系列データに基づいて、経時的に構築されるものである。分析機能は、同様に、リアルタイムで分析エンジン272へ渡され、そして、特徴データベース270内に保管される。
【0042】
インライン分析エンジン272は、メッセージバス上でメッセージハンドラーを介して特徴を受信する。実行されるタスクの１つは、アクティビティ分類(278)であり、これは、受信した特徴値／セッション情報に基づいてセッションに関連するアクティビティ(ファイルダウンロード、ログイン／認証プロセス、または、ディスクバックアップアクティビティ、といったもの)を識別するように試み、そして、適用可能なタグを付加する。アクティビティ分類278を実施する一つの方法は、畳み込みニューラルネットワークと組み合わされたニューラルネットワークベースの多層パーセプトロンを介するものである。
【0043】
アクティビティ分類の結果、特定のデバイスが印刷アクティビティに従事している(すなわち、印刷プロトコルを使用している)と判断され、そして、また、(例えば、HP URLを呼び出し、かつ、ステータス情報をレポートするために使用することによって、更新についてチェックするために)HPによって所有されるリソースにも定期的にコンタクトしていると仮定する。様々な実施形態において、分類情報は、クラスタリングプロセス(教師なし)および予測プロセス(教師あり)の両方に渡される。いずれかのプロセスが装置の分類に成功した場合、分類は、装置データベース286内に保管される。
【0044】
装置は、ステージ１クラスタリングエンジン280によって、その属性および他の挙動パターンに基づいて、複数のクラスタへとクラスタ化することができる。クラスタリングエンジン280を実装する一つの方法は、極端な勾配ブーストフレームワーク(例えば、XGB)を使用することである。ステージ１の分類器は、これまで見られなかったが、既存の既知の装置に類似する、装置を分類するために有用であり得る(例えば、サーモスタットの新規ベンダーが、既知のサーモスタットと同様に動作するサーモスタット装置を販売し始める)。
【0045】
図2Gに示されるように、アクティビティ分類情報も、また、分類器282のセットに提供され、そして、予測が、装置に対する提供された特徴に基づいて実行される。２つの可能性が生じ得る。第１シナリオでは、デバイスが既知のデバイスプロファイルと一致する高い可能性が存在すると判断される(すなわち、高い信頼スコア)。もしそうであれば、装置に関する情報は、(例えば、提供された情報および任意の追加の適用可能なコンテキスト情報を使用して)装置の識別のための最終判断を行うステージ２分類器(284)に提供され、そして、それに従って、装置データベース286を更新する。ステージ２分類器を実装する一つの方法は、勾配ブースティングフレームワークを使用することである。２番目のシナリオでは、信頼スコアが低い(例えば、デバイスがHPプリンタとHPラップトップの両方に50%の信頼度でマッチしている)と仮定する。このシナリオにおいて、分類器282によって決定された情報は、クラスタリングにおいて使用可能な追加情報として、クラスタリングエンジン280に提供され得る。
【0046】
図2Gには、また、オフラインモデリングモジュール299も示されている。オフラインモデリングモジュール299は、時間制約がないので、インライン分析エンジン272と対照的である(一方で、インライン分析エンジン272は、リアルタイムに(例えば、メッセージ234として)デバイス分類情報を提供するように試みる)。定期的に(例えば、1日1回、または、1週間1回)、オフラインモデリングモジュール299(例えば、Pythonを使用して実装されるもの)は、インライン分析モジュール272によって使用されるモデルを再構築する。アクティビティモデリングエンジン288は、アクティビティ分類器278のためのモデルを構築する。このモデルは、また、インライン分析の最中にデバイス識別のために分類器によって使用される、デバイスタイプモデル(296)にも使用される。ベースラインモデリングエンジン290は、デバイスモデルのベースライン挙動のモデルを構築する。このモデルは、また、特定のタイプのデバイス異常(292)およびキルチェーン（kill chain）といった、特定のタイプの脅威(294)をモデル化する際にも使用される。生成されたモデルは、様々な実施形態において、モデルデータベース298に保管される。
【0047】
ＩＶ．ネットワークエンティティID AAA
【0048】
前述のように、Aliceが、アクメ（ACME）によってノートパソコン104を発行されたと仮定する。ネットワーク110の種々のコンポーネントは、彼女が様々なリソースにアクセスするためにそれを使用する際に、Aliceのラップトップを認証するために協働する。一つの例として、Aliceがラップトップ104をネットワーク110(図示なし)内に置かれた無線アクセスポイントに接続するとき、無線アクセスポイントは、ネットワークアクセスを提供しながら、AAAサーバ156と通信することができる。別の例として、Aliceがラップトップ104を使用して彼女のアクメ電子メールにアクセスするとき、ラップトップ104は、彼女の受信ボックスをフェッチしながら、ディレクトリサービス154と通信することができる。コモディティオペレーティングシステムを実行するコモディティラップトップとして、ラップトップ104は、必要とする適切なリソースへのアクセスをラップトップ104が得るのを助ける、適切なAAAメッセージ（例えば、RADIUSクライアントメッセージ）を生成することができる。
【0049】
上述のように、110といったネットワークにおいてIoTデバイス(例えば、デバイス146)によって提起される１つの問題は、そうしたデバイスが、しばしば、「非管理（“unmanaged”）」(例えば、設定、プロビジョン、ネットワーク管理者に管理がされない、等)であり、RADIUSといったプロトコルをサポートしておらず、そして、従って、ラップトップ104など他のデバイスといったAAAサービスと統合できないことである。IoTデバイスにネットワーク110内のネットワークアクセスを提供するために、種々のアプローチを採用することができ、それぞれが欠点を有している。１つのオプションは、アクメについて、ゲストネットワークの使用を(例えば、事前共有鍵（pre-shared key）を介して)IoTデバイスに制限することである。残念ながら、このことは、IoTデバイスが、合法的にアクセスを有するべきネットワーク110内の他のノードと通信できない場合に、IoTデバイスのユーティリティを制限する可能性がある。別のオプションは、セグメント化されたネットワークを有することのセキュリティ上の利点を緩和しながら、ネットワーク110への無制限のアクセスをIoTデバイスに許容することである。さらに別のオプションは、アクメについて、所与のIoTデバイスがネットワーク110内のリソースにアクセスできる方法を支配するルールを手動で指定することである。このアプローチは、一般的に、様々な理由により、支持できない／実施不可能なものである。一つの例として、管理者は、しばしば、IoTデバイスの展開に関与せず、そして、従って、そうしたデバイスについてポリシが含まれるべきであることを知らない(例えば、データアプライアンス102)。管理者が、例えば、アプライアンス102内の特定のIoTデバイスについて(例えば、デバイス112といったデバイスについて)手動でポリシを設定する場合でさえ、そうしたポリシを最新の状態に保つことは、エラーを起こしやすく、そして、ネットワーク110内に存在し得る多くのIoTデバイスの数を考えると、一般的に、不可能である。さらに、そうしたポリシは、おそらく単純であり(例えば、IPアドレス及び／又はMACアドレスによって、CTスキャナ112を特定のネットワークに割り当てること)、そして、CTスキャナ112を含む接続／ポリシについてより細かく制御することはできない(例えば、外科装置と販売端末に適用可能なポリシを動的に含むこと)。さらに、前述のように、CTスキャナ112がデータアプライアンス102に手動で含まれる場合でさえ、IoTデバイスは、一般的に、RADIUSといった技術をサポートせず、そして、そうしたAAAサーバにCTスキャナ112のネットワークアクセスを管理させることの利点は、そうした技術をより完全にサポートする他のタイプの装置(例えば、ラップトップ104)と比較して制限される。以下で、さらに詳細に説明されるように、様々な実施形態において、データアプライアンス102は(例えば、IoTサーバ134を介して)、受動的なやり方で、ネットワーク110内に存在するIoTデバイスに対してAAA機能性についてサポートを提供するように構成されている。
【0050】
以下の説明においては、アクメにおけるAliceの部門が、最近、インタラクティブなホワイトボード146を購入し、その結果、Aliceが、他のアクメ従業員、並びに、アクメ外部の個人(例えば、自身のネットワーク114、データアプライアンス136、およびホワイトボード144を有している、ベータ大学の研究者である、Bob)と協働できる、と仮定する。ホワイトボード146の初期セットアップの一部として、Aliceは、電源に接続し、そして、有線（wired）接続(例えば、会議室のコンセント)、または、無線クレデンシャル(例えば、会議室の訪問者による使用のためのクレデンシャル)を提供する。ホワイトボード146がネットワーク接続を提供すると、IoTサーバ134は(例えば、上述のようなネットワークセンサといったメカニズムを介して)、ホワイトボード146をネットワーク110内の新しいデバイスとして認識する。この検出に応答してとられる一つのアクションは、セキュリティプラットフォーム140と通信することである(例えば、データベース160内にホワイトボード146のために新しいレコードを作成すること、および、ホワイトボード146に関連する現在利用可能なコンテキスト情報を検索すること(例えば、ホワイトボード146の製造業者、ホワイトボード146のモデル、等を獲得すること))。セキュリティプラットフォーム140によって提供される任意のコンテキスト情報は、適用できる場合、ディレクトリサービス154及び／又はAAAサーバ156に、順に提供することができる、データアプライアンス102に対して提供され、（そして、保管される）。適用できる場合、IoTモジュール138は、ホワイトボード146に関する更新されたコンテキスト情報を、それが利用可能になったときに、データアプライアンス102に提供することができる。そして、データアプライアンス102は(例えば、IoTサーバ134を介して)、同様に、ホワイトボード146に関する進行中の情報をセキュリティプラットフォーム140に提供することができる。そうした情報の例は、ホワイトボード146といったデバイスについて挙動プロファイルを構築するためにセキュリティプラットフォーム140によって使用することができるネットワーク110上のホワイトボード146の挙動に関する観察(例えば、接続に関する統計情報)を含む。同様な挙動プロファイルは、他のデバイス(例えば、ホワイトボード144)のセキュリティプラットフォーム140によって構築することができる。そうしたプロファイルは、異常な挙動の検出を含む、様々な目的に使用することができる。一つの例として、データアプライアンス148は、セキュリティプラットフォーム140によって提供される情報を使用することができ、温度計152が、温度計152の過去の観察結果と比較して異常に動作しているか否か、及び／又は、類似のモデル、製造者、または、より一般的には、他のネットワーク内に存在する温度計を含む、他の温度計（図示なし）と比較して異常に動作しているか否かを検出する。異常挙動が(例えば、データアプライアンス148によって)検出された場合、ネットワーク116上の他のノードへの温度計152のアクセスを制限する、警告を発生する、等といった、適切な修復措置を自動的にとることができる。
【0051】
図3は、ネットワークにおけるIoTデバイスについてAAAサポートを受動的に提供するためのプロセスに係る実施形態を示している。様々な実施形態において、プロセス300は、IoTサーバ134によって実行される。本プロセスは、IoTデバイスによって送信されたパケットのセットが取得されると、302で開始される。一つの例として、ホワイトボード146が最初にネットワーク110上に提供されるとき、そうしたパケットは、IoTサーバ134によって302で受動的に受信され得る。パケットは、また、ホワイトボード146のその後の使用の最中に(例えば、Aliceがホワイトボード144を介してBobとホワイトボードセッションする際に)、302で受信することもできる。304において、データパケットのセットに含まれる少なくとも１つのパケットが分析される。304で実行される処理の一つの例として、IoTサーバ134は、302で受信されたパケットがホワイトボード146によって送信されていると判断する。IoTサーバ134がとることができる１つのアクションは、ネットワーク110上の新しいIoTデバイスとしてホワイトボード146を識別し、そして、適用可能の場合、IoTモジュール138からコンテキスト情報を獲得することである。306において、IoTサーバ134は、IoTデバイスに代わり、IoTデバイスに関連する情報を含むAAAメッセージを送信する。そうしたメッセージの一つの例を図4Aに示されている。上述のように、ホワイトボード146はRADIUSプロトコルをサポートしていない。しかしながら、IoTサーバ134は、ホワイトボード146に代わり、(例えば、302において、そして、また、適用できる場合は、セキュリティプラットフォーム140からも受信される情報を使用して)図4Aに示されているようなメッセージを生成することができる。上述のように、IoTサーバ134がホワイトボード146に関する情報をIoTモジュール138に提供するとき、IoTモジュール138は、様々なアクションをとることができる。データベース160内にホワイトボード146に関するレコードを作成すること、そして、そのレコードにホワイトボード146に関するコンテキスト情報を取り込むこと（例えば、その製造業者、モデル番号、等を決定すること）、といったものである。ホワイトボード146に関する追加のコンテキスト情報がセキュリティプラットフォーム140によって収集されると、そのプロファイルは更新され、そして、データアプライアンス102に対して伝搬され得る。ホワイトボード146が最初にネットワーク110内に提供されたとき、追加のコンテキスト情報は利用可能でなくてよい(例えば、セキュリティプラットフォーム140は、そうした追加情報を有しておらず、または、そうした情報をセキュリティプラットフォーム140によってIoTサーバ134に提供することは、瞬時でなくてよい)。従って、そして、図4Aに示されるように、ホワイトボード146に代わりIoTサーバ134によって生成されたRADIUSメッセージは、限定された情報を含み得る。追加のコンテキスト情報が受信されると(例えば、IoTモジュール138からIoTサーバ134によって)、ホワイトボード146に代わりIoTサーバ134によって送信される後続のRADIUSメッセージは、そうした追加情報によって豊富にされ得る。そうした後続のメッセージの例が、図4Bおよび図4Cに示されている。図4Bは、一旦、IoTモジュール138によってホワイトボード146に関するコンテキスト情報が提供されると、IoTサーバ134がホワイトボード146に代わり送信することができるRADIUSメッセージの例を示している(例えば、幅広いIoTデバイスに関するコンテキスト情報のデータベースを含む)。図4Bに示される例では、ホワイトボードの製造者(Panasonic)およびデバイスの性質(例えば、対話型ホワイトボードである)といったコンテキスト情報が含まれている。そうしたコンテキスト情報は、AAAサーバ156といったAAAサーバによって使用されて、（ホワイトボード146を修正する必要なく）AAAサービスをホワイトボード146に提供することができる。電話会議装置専用のサブネットワーク上に自動的に提供することによる、といったものである。他のタイプのIoTデバイスも、また、デバイスタイプ、目的、等といった属性に基づいて、自動的にグループ化することができる(例えば、重要な外科用機器は、そうした機器専用のサブネットワーク上に自動的に提供され、そして、従って、ネットワーク上の他の機器から隔離されている)。そうしたコンテキスト情報は、トラフィックシェピングポリシといったポリシを実施するために使用することができる。(例えば、APP-IDを使用して決定される際に)ソーシャルネットワーキングパケット上のホワイトボード146パケットに優先的な扱いを与えるポリシ、といったものである。微細化（fine-grained）された方針は、同様に、重要な手術機器との通信に適用され得る(例えば、そうした機器と通信する任意の機器を時代遅れのオペレーティングシステムを持たないようにする、等)。図4Cに示される例では、さらに、より多くの追加のコンテキスト情報が、ホワイトボード146の代わりに、RADIUSメッセージ内に、IoTサーバ134によって含まれている。そうした追加のコンテキスト情報は、デバイスモデル、オペレーティングシステム、および、オペレーティングバージョンといった、追加の属性情報を含む。ホワイトボード146が最初にネットワーク110で提供されるとき、図4Cに示される全てのコンテキスト情報は、おそらく利用可能ではない。ホワイトボード146がネットワーク110内で経時的に使用されると、追加のコンテキスト情報が収集するされ得る(例えば、IoTサーバ134が、ホワイトボード146からのパケットを受動的に観察し続け、そして、セキュリティプラットフォーム140に情報を提供する際に)。この追加情報は、細分化されたポリシを実施するために(例えば、データアプライアンス102によって)活用することができる。一つの例として、図4Cに示されるように、ホワイトボード146は、Linuxベースであり、かつ、バージョン3.16を有する特定のオペレーティングシステムを実行する。頻繁に、IoTデバイスは、アップグレード可能／パッチ不可であるオペレーティングシステムのバージョンを実行する。そうしたデバイスは、それらのオペレーティングシステムに対するエクスプロイト（exploits）が開発されると、セキュリティリスクを引き起こし得る。データアプライアンス102は、コンテキスト情報に基づいたセキュリティポリシを実装することができる。時代遅れのオペレーティングシステムを有するIoTデバイスをネットワーク110内の他のノードから分離すること(または、そうでなければ、それらのアクセスを制限すること)、一方で、現在のオペレーティングシステムを有するものに対してより制限の少ないネットワークアクセスを許可すること、等による、といったものである。
【0052】
図4Aから図4Cは、RADIUSアクセス要求メッセージの例を示している。適用可能な場合に、IoTサーバ134は、ホワイトボード146の代わりに種々のタイプのRADIUSメッセージを生成することができる。一つの例として、RADIUSアカウンティング開始メッセージは、ホワイトボード146からのトラフィックが最初に観察されたときに、トリガされ得る。定期的なRADIUSアカウンティング中間更新メッセージは、ホワイトボードが使用されている間に送信することができ、そして、RADIUSアカウンティング停止メッセージは、ホワイトボード146がオフラインになったときに送信することができる。
【0053】
Ｖ． IoTデバイスの発見および識別
【0054】
上述のように、(例えば、IoTモジュール138を介して)セキュリティプラットフォーム140によって実行される１つのタスクは、IoTデバイス分類である。一つの例として、IoTサーバ134がデバイス発見メッセージをIoTモジュール138へ送信すると、IoTモジュール138は、デバイスについて分類を決定し、そして、応答を試みる(例えば、図2Cで示される評決234)。デバイスは、IoTモジュール138によってユニークな識別子と関連付けられ、その結果、適用できる場合、デバイスの後続の分類は、実行される必要がない(または、適用できる場合、そうでなければ実行されるであろう頻度よりも少ない頻度で実行される)。また、上述のように、決定された分類は(例えば、データアプライアンス102によって)使用され、デバイスへ／からのトラフィックに対するポリシを実施することもできる。
【0055】
様々なアプローチが、デバイスを分類するために使用され得る。第１アプローチは、組織固有の識別子(organizationally unique identifier、OUI)、それが実行するアプリケーションのタイプ、等といった、デバイスの静的属性を活用するルール/ヒューリスティックのセットに基づいて分類を実行することである。第２アプローチは、デバイスの動的であるが、ネットワークトラフィックから抽出された事前定義された属性(例えば、１日に送信されるパケットの数)を活用する、機械学習技術を使用して分類を行うことである。残念ながら、これらのアプローチは両方とも弱点を有している。
【0056】
ルールベースのアプローチは、一般的に、IoTデバイスのタイプごとに別個のルールを手動で作成する必要がある(デバイスの署名のタイプについて、署名としてどの属性／値が使用されるべきかを記述する)。このアプローチによって提示される１つの課題は、どの署名がデバイスの識別に関連し、かつ、他のデバイスの特徴の中でユニークである、の両方であるかを決定することである。さらに、ルールベースのアプローチでは、トラフィックから容易に取得できる限定された数の静的属性が利用可能である(例えば、ユーザーエージェント、OUI、URL宛先、等)。属性は、一般的に、正規の（regular）表現がマッチするパターンで表示されるように、十分に単純である必要がある。もう１つの課題は、新しいデバイスがマーケットに参入する際に(例えば、CTスキャナの新しいブランドまたはやモデルが提供される)、存在／識別可能な新しい静的属性を特定することである。別の課題は、ルールをトリガするために、ネットワークトラフィック内の全てのマッチング属性を収集する必要があることである。より少ない属性を用いて評決に至ることはできない。一つの例として、署名は、特定のURLに接続するために、特定のOUIを有する特定のデバイスを必要とし得る。OUIを有すること自体は、既にデバイスのアイデンティティの十分なインジケータであり得るが、URLも、また、観察されるまで、署名はトリガされない。このことは、デバイスのアイデンティティを決定することに、さらなる遅れを生じさせるだろう。別の１つの課題は、(例えば、デバイス、または、デバイスで使用されるサービスに対して行われる更新のために)経時的に変化するデバイスについて静的属性として、署名を維持および更新することである。一つの例として、特定のデバイスは、最初、第１タイプのネットワークカードを使用して製造されたかもしれないが、時間が経つと、製造者は、(異なるOUIを示す)異なるネットワークカードに切り替え得る。ルールベースのシステムが変更を認識していない場合、偽陽性（false positive）が発生し得る。さらに別の課題は、毎日オンラインに持ち込まれる新たなIoTデバイスの数が何百万もの新たなIoTデバイスインスタンスに近づく場合に、署名生成／検証をスケーリングすることである。その結果、新たに作成されたルールが、既存のルールと矛盾し、そして、分類における偽陽性を引き起こし得る。
【0057】
機械学習ベースのアプローチは、一般的に、ネットワークトラフィックから抽出された静的及び／又は動的特徴に基づくトレーニングモデルを作成することを含んでいる。新しいIoTデバイスからのネットワークデータの予測結果は、関連する精度を有するデバイスのアイデンティティを提供する予備訓練（pre-trained）モデルに基づいている。機械学習アプローチに伴う問題の例は、以下のとおりである。所望の精度に到達するために必要な計算時間は、予測が全ての新しいデバイス、または、一定／一意のID(例えば、MACアドレス)を有していないデバイスについて行われる場合、受け入れられことがあり得る。生成される必要のある機能は、数千または数万個も存在し得るものであり、そして、これらの機能は、有効な予測を行うために十分な数の機能が利用可能になるまでに、著しい時間を要して(ポリシ実施の目的を損なう可能性がある)、事前に定義された時間枠にわたり変換され得る。さらに、予測の遅れを最小にすることを目標とする場合には、ストリーミングネットワークデータのための大規模なデータパイプラインを構築し、そして、維持するためのコストが高くなり得る。さらに別の問題は、所与の展開環境に特有の無関係な特徴によってもたらされるノイズが、予測の精度を低下させ得ることである。そして、デバイスタイプの数が数万以上に達すると、モデルの維持および更新について課題が存在する。
【0058】
様々な実施形態において、セキュリティプラットフォーム140は、分類に対するハイブリッドアプローチを使用することによって、上述の２つのアプローチそれぞれの問題に対処する。一つの例示的なハイブリッドアプローチにおいて、ネットワーク挙動パターン識別子(ここにおいては、また、パターンIDとも呼ばれるもの)が、デバイスの各タイプについて生成される。様々な実施形態において、パターンIDは、属性またはシーケンス特徴のリストであり、(特徴または挙動カテゴリの重要度スコアとして)それらのそれぞれの確率と組み合わされ、別個のネットワーク行動記述を形成し、そして、IoTデバイスのタイプを識別するために使用され得る。パターンIDは、(例えば、データベース内に)保管され、そして、デバイスの識別／検証のために使用され得る。
【0059】
属性のセットについてトレーニングするとき、極端なグラデーションブースティングフレームワーク(例えば、XGB)といった、特定のアプローチが、重要な特徴のトップリスト(静的属性、動的属性、及び／又は、集約／変換値のいずれか)を提供することができる。パターンIDは、一旦確立されたデバイスタイプを一意に識別するために使用することができる。特定の特徴がデバイスについて支配的である場合(例えば、特定の静的特徴(ブート時に高度に特定的なURLにコンタクトする、といったこと)は、98%の信頼度でデバイスを識別する)、それらは、自動的にルールを生成するために使用され得る。支配的な特徴が存在しない場合でさえ、それにもかかわらず、トップの特徴（top features）の表現がパターンIDとして使用され得る(例えば、複数の特徴のセットがパターンの中へに連結される場合)。全ての既知のモデル(および、全ての既知のIoTデバイス)を含むデータセットについてトレーニングすることによって、モデル間／一意に識別する特徴間の潜在的な競合を回避することができる。さらに、パターンIDは、人間が読むことができるものである必要はない(しかし、識別目的のために、保管、共有、及び／又は再利用することができる)。このアプローチによって、著しい時間節約も、また、実現することができ、その結果、リアルタイムに近い分類で使用することができる。支配的な特徴が観察されるとすぐに、(多数の特徴が生じるまで待つ必要の代わりに)特定のデバイスの分類が生じ得る。
【0060】
「Teem Room Display iPad（登録商標）」デバイスについてパターンIDを作成するために使用され得るデータの一つの例は、以下を含むことができる(多変量モデルのトレーニングまたは複数のバイナリモデルのトレーニングを通じて自動的に生成される完全なリストを伴う)。
【0061】
＊Appleデバイス(100%)
【0062】
＊Special iPad(>98.5%)
【0063】
＊Teem Room App(>95%)
【0064】
＊Meeting volume pattern VPM-17(>95%)
【0065】
＊Server-in-the-cloud(>80%)
【0066】
ハイブリッドアプローチの一つの例示的な方法は、以下のとおりである。ニューラルネットワークベースの機械学習システムが、自動パターンIDトレーニングおよび生成のために使用することができる。ニューラルネットワークモデルをトレーニングするために使用され得る特徴の例は、ネットワークトラフィックから抽出された静的特徴(例えば、OUI、ホスト名、TLSフィンガープリント、マッチド（matched）L7ペイロード署名、等)、および、ネットワークトラフィックから抽出されるが、環境に特有ではないシーケンス特徴(例えば、アプリケーションのL7属性、カテゴリ特徴へ変換されるボリューム範囲、等)の両方を含んでいる。軽量データパイプラインが、リアルタイムでの特徴生成のために、選択されたネットワークデータをストリームするために使用され得る。予測エンジンは、モデルをインポートし、そして、予測における遅延を最小限に抑えるためのキャッシュを提供する。予測においては、選択されたシーケンス特徴を安定化するために、短い(例えば、分ベースの)集約（aggregation）が使用され得る。カスタマイズされたデータの正規化、濃縮、集約、および変換技術は、シークエンス特徴を設計するために使用され得る。より長い集約ウィンドウは、より正確なトレーニングのために使用され得る。精度は、経時的にマージされ、そして、集約される特徴を用いて、予測について改善され得る。バックエンドフィードバックエンジンを使用して、パターンID予測に使用される属性の拡張を助ける「低速経路（“slow path”）」予測システム(例えば、デバイスタイプモデリングサブシステムおよびデバイスグループモデリングサブシステムを含む機械学習ベースのアプローチ)の結果をルーティングすることができる。デバイスグループモデルは、十分なサンプルまたは特徴が利用可能でない場合に、デバイスタイプモデルに伴う問題を補償するようにトレーニングすることができ、許容閾値を超える精度を改善する(例えば、事前に定義されたタイプのセットに基づいて予測結果を割り当て、そのうちのいくつかは、ラベルなしの類似タイプのデバイスをクラスタ化するための別のサブシステムを伴う)。最後に、リアルタイム予測エンジンからの結果を公表するために、評決モジュールが使用され得る。
【0067】
ここにおいて説明されるような分類に対するハイブリッドアプローチの例示的な利点は、以下のとおりである。第一に、高速コンバージェンスが発生し、所与のデバイスについて、数分または数秒以内に識別される可能性があることである。第二に、ルールベースのシステムおよび機械学習ベースのシステムの個々の問題を扱うことである。第三に、予測結果における安定性および一貫性を提供することである。第四に、数万(または、それ以上)の異なるタイプのIoTデバイスをサポートするスケーラビリティを有することである。予測は、一般的に、(所与のデバイスがL3ネットワークトラフィックベースの識別といった、一意のID割り当てを欠いていても)新しいデバイスについてのみ必要とされる。
【0068】
モジュール138の一つの実施形態が図5に示されている。IoTモジュール138を実装する一つの例示的な方法は、サービスが細分化され、そして、プロトコルが軽量化されている、マイクロサービスベースのアーキテクチャを使用することである。サービスは、また、適用できる場合、異なるプログラミング言語、データベース、ハードウェア、およびソフトウェア環境、及び／又は、メッセージングがイネーブルされ、コンテキストにより制限され、自律的に開発され、独立して展開可能であり、分散化され、そして、自動化されたプロセスで構築され、かつ、リリースされる、比較的小規模なサービスを使用して、実施することもできる。
【0069】
上述のように、様々な実施形態において、セキュリティプラットフォーム140は、ネットワーク(例えば、ネットワーク110)上のIoTデバイスに関する情報を(例えば、データアプライアンス102から)周期的に受信する。ある場合に、IoTデバイスは、セキュリティプラットフォーム140によって以前に分類されている(例えば、昨年ネットワーク110にインストールされたCTスキャナ)。他の場合には、IoTデバイスは、セキュリティプラットフォーム140によって新たに見られる(例えば、最初にホワイトボード146がインストールされたとき)。所与のデバイスが、セキュリティプラットフォーム140によって以前に分類されていないと仮定する(例えば、一意のデバイス識別子および関連するデバイス情報のセットが保管されているデータベース286内に、デバイスに対するエントリが存在しない)。図5に示されるように、新しい装置に関する情報は、分類のために２つの異なる処理パイプラインへ提供され得る。パイプライン504は、「高速経路（“fast path”）」分類パイプライン(パターンIDベースのスキームに対応している)を表し、そして、パイプライン502は、「低速経路（“slow path”）」分類パイプライン(機械学習ベースのスキームに対応している)を表す。
【0070】
パイプライン504においては、高速経路特徴エンジニアリングが実行され(508)、デバイスの適用可能な静的およびシーケンス特徴を識別する。高速経路予測は、パターンIDまたは以前に構築されたモデル(例えば、トップの重要な特徴に基づき、かつ、オフライン処理パイプライン506を使用して構築されたモデル)を使用して実行される(510)。特定のパターンにマッチングするデバイスについて信頼スコアが決定される(512)。装置の信頼スコアが、予めトレーニングされた閾値(例えば、モジュール138またはコンポーネントの全体的な予測精度に基づくものであり、例えば0.9)を満たす場合に、分類は、(デバイスデータベース516内の)デバイスに割り当てられ、または、適用できる場合に、更新され得る。最初に、信頼スコアは、リアルタイムに近い高速経路処理に基づいている。このアプローチの利点は、データアプライアンス102が、デバイスのトラフィックに対して非常に迅速に(例えば、モジュール138が、新たな／分類されていないものとしてデバイスを識別する数分以内に)ポリシの適用を開始することができることである。アプライアンス102は、システム140からの分類評決を待つ間、フェールセーフ（fail-safe）(例えば、様々なネットワークリソースへアクセスするためのデバイスの能力を低減／制限する)、または、フェールデインジャ（fail-danger）(例えば、デバイスの幅広いアクセスを可能にする)に構成することができる。追加情報が(例えば、低速経路処理を介して)利用可能になると、信頼スコアは、適用できる場合、その追加情報に基づくことができる(例えば、信頼スコアの増加、または、高速経路分類の最中になされた誤りの訂正／修正)。
【0071】
使用され得る例示的な特徴(例えば、静的属性およびシーケンス特徴)は、以下を含んでいる。パターンIDは、論理条件を含む、これらの属性の任意の組み合わせであり得る。
【0072】
＊macアドレスにおけるOUI
【0073】
＊デコードされたプロトコルからのホスト名ストリング
【0074】
＊HTTP、および、他のクリアテキストプロトコルからのユーザエージェントストリング
【0075】
＊デコードされたSNMP応答からのシステム名ストリング
【0076】
＊デコードされたLDAPプロトコルからのOS、ホスト名、ドメイン、およびユーザ名
【0077】
＊デコードされたDNSプロトコルからのURL
【0078】
＊デコードされたSMBプロトコルからの、SMBバージョン、コマンド、エラー
【0079】
＊TCPフラグ
【0080】
＊デコードされたDHCPプロトコルからのオプションストリング
【0081】
＊Digital Imaging and Communications in Medicine(DICOM)といったデコードされたIoTプロトコルからのストリング
【0082】
＊ローカルネットワークからのインバウンドアプリケーションのリスト
【0083】
＊インターネットからのインバウンドアプリケーションのリスト
【0084】
＊ローカルネットワークへのアウトバウンドアプリケーションのリスト
【0085】
＊インターネットへのアウトバウンドアプリケーションのリスト
【0086】
＊ローカルネットワークからのインバウンドサーバポートのリスト
【0087】
＊インターネットからのインバウンドサーバポートのリスト
【0088】
＊ローカルネットワークへのアウトバウンドサーバポートのリスト
【0089】
＊インターネットへのアウトバウンドサーバポートのリスト
【0090】
＊ローカルネットワークからのインバウンドIPのリスト
【0091】
＊インターネットからのインバウンドURLのリスト
【0092】
＊ローカルネットワークへのアウトバウンドIPのリスト
【0093】
＊インターネットへのアウトバウンドURLのリスト
【0094】
場合によっては、512で決定された信頼スコアが非常に低いことがある。このこと起こり得る１つの理由は、デバイスが新しいタイプであり(例えば、新しいタイプのIoT玩具、または、セキュリティプラットフォーム140によって以前に分析されていない他のタイプの製品)、そして、セキュリティプラットフォーム140上のデバイスについて利用可能な対応するパターンIDが存在しないからである。そうしたシナリオにおいて、デバイスおよび分類結果に関する情報は、オフライン処理パイプライン506に提供され得る。これは、例えば、デバイスおよび他の適用可能な情報によって示される挙動に対してクラスタリングを実行することができる(514)(例えば、デバイスが、無線装置であること、プリンタのように動作すること、DICOMプロトコルを使用すること、等を決定するためである)。クラスタリング情報は、ラベルとして適用され、そして、適用可能な場合には、追加リサーチ518のためにフラグ付けされ、その後、同様なデバイスが自動的にグループ化されるように見える。リサーチの結果、所与のデバイスに関する追加情報が決定された場合(例えば、それが新しいタイプの消費者指向のIoT食肉温度計に対応するものとして識別された)、デバイス(および、同様な特性を有する他の全てのデバイス)は、それに応じて(例えば、ブランドXYZ食肉温度計として)再度レベル付けされ、そして、関連するパターンIDが生成され、そして、適用できる場合には、(例えば、モデルが再構築された後で)パイプライン502/504によって使用可能となる。様々な実施形態において、オフラインモデリング520は、IoTデバイス識別のために使用される様々なモデル522をトレーニングし、かつ、更新するために毎日実行されるプロセスである。様々な実施形態において、モデルは、新しいラベル付きデバイスをカバーするために毎日更新され、そして、挙動の変化を反映するために毎週再構築され(低速経路パイプライン502について)、そして、週の最中に追加された新しい特徴およびデータの洞察を収容する。セキュリティプラットフォーム140に新しいタイプのデバイスを追加する場合(すなわち、新しいデバイスパターンを作成する場合)、複数の既存のデバイスパターンが影響を受ける可能性があり、特徴またはそれらの重要度スコアのリストのいずれかが更新されることを要求していることに留意されたい。本プロセスは、自動的に実行することができ(そして、ルールベースのソリューションと比較して大きな利点である)。
【0095】
高速経路モデリングのために、ニューラルネットワークベースモデル(例えば、FNN)、および、一般機械学習モデル(例えば、XGB)が多変量分類モデルのために広く使用されている。結果を改善し、クラスタリングへのインプットを提供するために、選択したプロファイルのバイナリモデルも、また、構築される。バイナリモデルは、デバイスの識別、または、デバイスの所定の挙動に対して「はい」／「いいえ」の回答を与える。例えば、バイナリモデルを使用して、デバイスがIP電話のタイプであるか、おそらくIP電話ではないか、いずれかを判断するために使用され得る。多変量モデルは、１の確率で正規化された多くの出力を有する。各出力は、デバイスのタイプに対応している。バイナリモデルは、一般的に、より速いが、正しい「はい」の回答を見つけるために、デバイスが多くの予測を経ることを要求するだろう。多変量モデルは、一段階でそれを達成することができる。
【0096】
低速経路パイプライン502は、特徴が抽出される点でパイプライン504と類似している(524)。しかしながら、パイプライン502によって使用される特徴は、典型的に、構築するのに一定の時間を要する。一つの例として、「１日あたりの送信バイト数（“number of bytes sent per day”）」の特徴は、収集するために１日を必要とする。別の例として、所定の使用パターンは、発生し／観察されるのに一定の時間を要し得る(例えば、CTスキャナがスキャンを実行するため１時間ごとに使用される(第１挙動)、毎日データをバックアップする(第２挙動)、および、製造業者のウェブサイトを更新のために毎週チェックする場合(第３挙動))。低速経路パイプライン502は、特徴の完全なセット上で新しいデバイスのインスタンスを分類する試みにおいて、多変量分類器を呼び出す(526)。使用される特徴は、静的またはシーケンス特徴に限定されるものではなく、ボリュームおよび時系列ベースの特徴も、同様に含んでいる。このことは、一般的に、第１段階の予測と呼ばれる。所定のプロフィールについて、第１段階の予測結果が最適でない場合(信頼度が低い)、その結果を改善する試みにおいて、第２段階の予測結果が使用される。低速経路パイプライン502は、新しいデバイスのインスタンスを分類するために、追加的にインポートされたデバイスのコンテキストによってサポートされる、ディシジョンツリー分類器のセットを呼び出す(528)。追加的なデバイスのコンテキストは、外部ソースからインポートされる。一つの例として、デバイスが接続したURLは、特徴として含めることができるカテゴリおよびリスクベースの評判を与えられ得る。別の例として、デバイスによって使用されるアプリケーションは、特徴として含めることができるカテゴリおよびリスクベースのスコアを与えられ得る。第１段階予測526および第２段階予測528からの結果を組み合わせることによって、導出信頼スコアを用いて低速経路分類の最終評決に到達することができる。
【0097】
一般的には、低速経路パイプライン502に含まれる２つの段階が存在している。低速経路パイプラインでは、いくつかの実施形態において、第１段階モデルが、ニューラルネットワーク技術に基づいて、多変量分類器を用いて構築される。低速経路パイプラインの第２段階は、一般的に、第１段階の確率関連の例外を処理するための追加的なロジックを備えた決定ベースモデルのセットである。予測において、第２段階は、第１段階からの入力を統合し、第１段階の出力を検証し、そして、低速経路の最終出力を生成するために、ルールおよびコンテキストを適用する。最終出力は、デバイスのアイデンティティ、全体的な信頼スコア、将来の高速経路パイプライン504に使用できるパターンID、および、説明リストを含んでいる。信頼スコアは、モデルの信頼性と精度(モデルは、また、信頼スコアも有する)、および、分類の一部としての確率に基づいている。説明リストは、結果に貢献する特徴のリストを含む。上述のように、結果が既知のパターンIDから逸脱した場合に、調査がトリガされ得る。
【0098】
いくつかの実施形態において、低速経路モデリングのために、２つのタイプのモデルが構築される。１つは個々のアイデンティティ用であり、そして、もう１つはグループのアイデンティティ用である。例えば、異なるベンダーから、または、異なるモデルの２台のプリンタ間の違いを見分けることは、しばしば、温度計からプリンタを区別することよりも困難である(例えば、プリンタは、ネットワーク挙動を示し、類似のプロトコルを話す傾向があるからである)。種々の実施形態においては、種々のベンダーからの種々のプリンタが、グループ内に含まれ、そして、「プリンタ」モデルは、グループ分類のためにトレーニングされる。このグループ分類結果は、特定のプリンタに対する特定のモデルよりも良好な精度を提供することができ、そして、デバイスの信頼スコアを更新するために、または、適用できる場合には、個々のプロファイルのアイデンティティベースの分類に対する参照および検証を提供するために使用することができる。
【0099】
図6は、IoTデバイスを分類するためのプロセスに係る一つの例を示している。様々な実施形態において、プロセス600は、セキュリティプラットフォーム140によって実行される。プロセス600は、また、適用できる場合には、他のシステムによっても実行可能である(例えば、IoTデバイスと敷地内（on-premise）で共配置されているシステム)。プロセス600は、IoTデバイスのネットワーク通信に関連付けられた情報が受信されると、602で開始される。一つの例として、そうした情報は、データアプライアンス102が所与のIoTデバイスに対するデバイス発見イベントを送信するときに、セキュリティプラットフォーム140によって受信される。604においては、デバイスが分類されていない(または、適用できる場合に、再分類が実施されるべきである)との判断が行われる。一つの例として、プラットフォーム140は、デバイスが分類されたか否かを判断するためにデータベース286をクエリ（query）することができる。606においては、２つの部分からなる（two-part）分類が実行される。一つの例として、２つの部分からなる分類は、606で、高速経路分類パイプライン504および低速経路分類パイプライン502の両方に対するデバイスに関する情報を提供するプラットフォーム140によって実行される。最後に、608では、606で実行された分類プロセスの結果が、IoTデバイスに対してポリシを適用するように構成されたセキュリティアプライアンスに提供される。上述のように、これにより、非常に細分化されたセキュリティポリシが、最小限の管理努力で、潜在的にミッションクリティカルな環境において実装され得る。
【0100】
プロセス600を実行する第１例において、Xbox Oneゲームコンソールがネットワーク110に接続されていると仮定する。分類中に、デバイスが以下の主要な特徴を有していると判断することができる。「ベンダー＝マイクロソフト（“vendor=Microsoft”）」特徴が100%の信頼性を有し、「マイクロソフトクラウドサーバと通信する（“communicates with Microsoft cloud server”）」特徴が89.7%の信頼性を有し、そして、「ゲーム機（“game console”）」特徴と78.5%の信頼性でマッチする。これら３つの特徴／信頼スコアは、プロファイルIDのセットに対して集合的にマッチングさせることができ(ニューラルネットワークベースの予測によって実行されるプロセス)、Xbox Oneゲームコンソールとしてデバイスを識別する(すなわち、512で、閾値を満たすプロファイルIDマッチが見つかる)。第２例においては、AudioCodes IP電話がネットワーク110に接続されていると仮定する。分類中に、デバイスが、「ベンダー=オーディオコード（“vendor=AudioCodes”）」特徴と100%の信頼性で、「IPオーディオデバイスである（“is an IP audio device”）」特徴と98.5%の信頼性で、および、「ローカルサーバのように動作する（“acts like a local sever”）」特徴と66.5%の信頼性でマッチすると判断することができる。これら３つの特徴／信頼スコアも、また、プロファイルIDのセットに対してマッチするが、このシナリオでは、既存のプロファイルIDは十分な信頼性でマッチしないと仮定している。デバイスに関する情報は、次いで、クラスタリングプロセス514に提供され、そして、適用可能な場合には、新しいプロファイルIDが最終的に生成されて、デバイスに関連付けされ得る(および、将来のデバイスを分類するために使用され得る)。
【0101】
適用可能な場合に、セキュリティプラットフォーム140は、決定された分類に基づいて、特定のポリシを推奨することができる。以下は、実施可能なポリシの例である。
【0102】
＊全ての輸液ポンプ（Infusion Pump）について(ベンダーに関係なく)インターネットトラフィックを拒否する
【0103】
＊所定のGEホストから／に対するものを除く、全てのGE ECGマシンについてインターネットトラフィックを拒否する
【0104】
＊全てのCTスキャナについて(ベンダーに関係なく)画像保存通信システム（Picture Archiving and Communication System、PACS)サーバへの内部トラフィックのみを許可する
【0105】
上述の実施形態は、理解を明確にするためにある程度詳細に説明されてきたが、本発明は、提供された詳細に限定されるものではない。本発明を実施するための多くの代替的な方法が存在している。開示された実施形態は、例示的なものであり、かつ、限定的なものではない。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図2F】
【図2G】
【図3】
【図4A】
【図4B】
【図4C】
【図5】
【図6】