知財求人 - 知財ポータルサイト「IP Force」
▶ パロ アルト ネットワークス，インコーポレイテッドの特許一覧
特許7592752統計的ペイロードフィンガープリントを使用した自動ＩＯＴデバイス識別
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-22
(45)【発行日】2024-12-02
(54)【発明の名称】統計的ペイロードフィンガープリントを使用した自動ＩＯＴデバイス識別
(51)【国際特許分類】
G06F 21/55 20130101AFI20241125BHJP
G06F 11/277 20060101ALI20241125BHJP
【ＦＩ】
G06F21/55
G06F11/277
【請求項の数】
11
(21)【出願番号】P 2022573510
(86)(22)【出願日】2021-06-01
(65)【公表番号】
(43)【公表日】2023-06-30
(86)【国際出願番号】 US2021035279
(87)【国際公開番号】W WO2021247598
(87)【国際公開日】2021-12-09
【審査請求日】2023-01-23
(31)【優先権主張番号】63/033,012
(32)【優先日】2020-06-01
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/133,177
(32)【優先日】2020-12-23
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】517392861
【氏名又は名称】パロ アルト ネットワークス，インコーポレイテッド
【氏名又は名称原語表記】Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．
【住所又は居所原語表記】３０００ Ｔａｎｎｅｒｙ Ｗａｙ，Ｓａｎｔａ Ｃｌａｒａ，Ｃａｌｉｆｏｒｎｉａ ９５０５４，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ワン，フェン
【審査官】小林 秀和
(56)【参考文献】
【文献】米国特許出願公開第２０２０／０１２０００４（ＵＳ，Ａ１）
【文献】特開２００７－０７４３３９（ＪＰ，Ａ）
【文献】国際公開第２０１４／０４９６６０（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ２１／５５
Ｇ０６Ｆ １１／２７７
(57)【特許請求の範囲】
【請求項1】
プロセッサおよびメモリを含む、システムであって、前記プロセッサは、
データ装置によって観察された、対応するフローを有するIoTデバイスにおいて実行されているアプリケーションについて、バイト頻度パターンを受信し、前記データ装置は、前記アプリケーションの分類を決定することができず、
前記IoTデバイスについて前記分類を決定するために、少なくとも部分的に閾値の一致に基づいて、受信した前記バイト頻度パターンの少なくとも一部を、以前に決定されたバイト頻度パターンと比較することを含み、前記アプリケーションについて受信したパターンを使用し、
かつ、
少なくとも部分的に前記分類に基づいて、前記IoTデバイスに対してポリシを適用するように構成されたセキュリティ装置に前記分類を提供する、
ように構成されており、
前記メモリは、前記プロセッサに結合されており、かつ、前記プロセッサに命令を提供するように構成されており、
前記閾値の一致は、少なくとも部分的に、複数の特徴に基づいており、前記複数の特徴を考慮することにより、前記分類の精度が向上する、
システム。
【請求項2】
前記バイト頻度パターンは、バイトフロー分布を含む、請求項１に記載のシステム。
【請求項3】
前記データ装置は、前記IoTデバイスをモニタリングするように構成されている、請求項１に記載のシステム。
【請求項4】
前記受信したバイト頻度パターンが、既存のバイト頻度プロファイルの閾値内にあるものと決定され、かつ、それに応じて、前記プロセッサは、前記プロファイルに関連付けられた他のデバイスと共に前記IoTデバイスを分類するように構成されている、
請求項１に記載のシステム。
【請求項5】
前記受信したバイト頻度パターンが、複数の既存のバイト頻度プロファイルの閾値外にあるものと決定され、かつ、それに応じて、前記プロセッサは、新しいプロファイルを生成するように構成されている、
請求項１に記載のシステム。
【請求項6】
前記分類は、少なくとも部分的に、モデルに基づいて決定される、請求項１に記載のシステム。
【請求項7】
前記モデルは、バイトフロー分布情報を含む一式の特徴を使用してトレーニングされる、請求項６に記載のシステム。
【請求項8】
前記バイト頻度パターンは、少なくとも部分的に、フローにおける事前定義された数のパケットに基づいて決定される、請求項１に記載のシステム。
【請求項9】
前記バイト頻度パターンは、トランスポート層ペイロードを使用して決定される、請求項１に記載のシステム。
【請求項10】
データ装置によって観察された、対応するフローを有するIoTデバイスにおいて実行されているアプリケーションについて、バイト頻度パターンを、システムによって、受信するステップであり、前記データ装置は、前記アプリケーションの分類を決定することができない、ステップと、前記IoTデバイスについて前記分類を決定するために、少なくとも部分的に閾値の一致に基づいて、受信した前記バイト頻度パターンの少なくとも一部を、以前に決定されたバイト頻度パターンと比較することを含み、前記アプリケーションについて受信したパターンを、前記システムによって、使用するステップと、
少なくとも部分的に分類に基づいて、前記IoTデバイスに対してポリシを適用するように構成されたセキュリティ装置に前記分類を、前記システムによって、提供するステップと、
を含み、
前記閾値の一致は、少なくとも部分的に、複数の特徴に基づいており、前記複数の特徴を考慮することにより、前記分類の精度が向上する、
方法。
【請求項11】
有形のコンピュータ可読記憶媒体に保管され、かつ、複数のコンピュータ命令を含む、コンピュータプログラムであって、前記命令がコンピュータのプロセッサによって実行されると、前記コンピュータに、請求項１０に記載の方法を実施させる、
コンピュータプログラム。
【発明の詳細な説明】
【背景技術】
【0001】
他の出願との相互参照
本出願は、2020年6月1日に出願されたタイトルが“IOT DEVICE CLASSIFICATION USING STATISTICAL FINGERPRINTS IN NETWORK TRAFFIC”である米国仮特許出願第63/033,012号について優先権を主張するものであり、それは、全ての目的について、参照により、ここにおいて組み込まれている。
本出願は、2020年6月1日に出願されたタイトルが“IOT DEVICE CLASSIFICATION USING STATISTICAL FINGERPRINTS IN NETWORK TRAFFIC”である米国仮特許出願第63/033,012号について優先権を主張するものであり、それは、全ての目的について、参照により、ここにおいて組み込まれている。
【0002】
極悪な個人（nefarious individuals）は、様々な方法でコンピュータシステムを侵害しようとする。一例として、そうした個人は、電子メールの添付ファイルに悪意のあるソフトウェア(「マルウェア（“malware”）」)を埋め込み、または、他の方法で含ませ、そして、疑わないユーザ（unsuspecting user）に対してマルウェアを送信し、または、送信させることができる。実行されると、マルウェアは、被害者のコンピュータが危険にさらし、そして、追加的な極悪のタスク(例えば、機密データの抽出、他のシステムへの伝播、等)を実行することができる。そうした侵害および他の侵害に対して、様々なアプローチが、コンピュータを強化するために使用される。残念ながら、コンピュータを保護することに対する既存のアプローチは、必ずしも全てのコンピューティング環境に適しているとは限らない。さらに、マルウェアの作成者は、検出を回避するために絶え間なく技術を適応させており、そして、様々な状況においてマルウェアを検出し、かつ、その害を防止するために、改善された技術に対する継続的な必要性が存在する。
【図面の簡単な説明】
【0003】
本発明の様々な実施形態は、以下の詳細な説明および添付図面において開示されている。
【発明を実施するための形態】
【0004】
本発明は、装置、システム、物事の組成、コンピュータ可読記憶媒体において具現化されたコンピュータプログラム製品、及び／又は、プロセッサに結合されたメモリに保管され、かつ／あるいは、メモリによって提供される命令を実行するように構成されたプロセッサといった、プロセッサを含む、様々な方法で実施することができる。この仕様書において、これらの実装、または本発明がとり得る他の形式は、技法（techniques）として称される。一般的に、開示されるプロセスのステップの順序は、本発明の範囲内で変更することができる。特に断りのない限り、タスクを実行するように構成されていると説明されるプロセッサまたはやメモリといったコンポーネントは、ある時点でタスクを実行するように一時的に構成されている一般的なコンポーネント、または、タスクを実行するように製造された特定のコンポーネントとして実装され得る。ここにおいて使用されるように、「プロセッサ（“processor”）」という用語は、コンピュータプログラム命令といった、データを処理するように構成された１つ以上のデバイス、回路、及び／又は、処理コアを参照する。
【0005】
本発明の１つ以上の実施形態の詳細な説明が、以下に、本発明の原理を説明する添付の図と共に提供される。本発明は、そうした実施形態に関連して説明されるが、本発明は、任意の実施形態についても限定されるものではない。本発明の範囲は、請求項によってのみ限定されるものであり、そして、本発明は、多数の代替、修正、および均等物を包含する。本発明について完全な理解を提供するために、以下の説明において、多数の具体的な詳細が記載されている。これらの詳細は、例示の目的で提供されるものであり、そして、本発明は、これらの具体的な詳細の一部または全部を用いることなく、請求項に従って実施され得る。明確にするために、本発明に関連する技術分野で知られている技術資料は、本発明が不必要に不明瞭にならないように、詳細には説明されていない。
【0006】
システムおよび方法が説明される。モノのインターネット(IoT)デバイスのネットワークトラフィックに関連するバイト頻度パターンが受信される。いくつかの態様において、バイト頻度パターンは、バイトフロー分布を含んでいる。いくつかの態様において、バイト頻度パターンは、少なくとも部分的に、フロー内の所定の数のパケットに基づいて決定される。いくつかの態様において、バイト頻度パターンは、トランスポート層ペイロードを使用して決定される。いくつかの態様において、バイト頻度パターンは、IoTデバイスをモニタリングするように構成されたデータ装置から受信される。受信されたパターンは、IoTデバイスの分類を決定するために使用される。いくつかの態様において、分類は、少なくとも部分的に、複数の特徴に基づくことができる、閾値の一致（threshold match）に基づいて決定される。受信したパターンが既存のバイト頻度パターンの閾値内にあると判断されたイベントにおいて、IoTデバイスは、プロファイルに関連付けられた他のデバイスに分類することができる。受信したパターンが既存の複数のバイト頻度プロファイルの閾値外にあると判断された場合、新しいプロファイルを生成することができる。いくつかの態様において、分類は、少なくとも部分的に、モデルに基づいて決定される。モデルは、バイトフロー分布情報を含む一式の特徴を使用して、トレーニングすることができる。分類は、少なくとも部分的に、分類に基づいて、IoTデバイスに対してポリシを適用するように構成された、セキュリティ装置に対して提供される。
【0007】
I.概要（OVERVIEW）
【0008】
ファイアウォールは、一般的に、不正アクセス（unauthorized access）からネットワークを保護し、一方で、承認された（authorized）通信がファイアウォールを通過するのを許可している。ファイアウォールは、典型的には、デバイスまたは一式のデバイス、または、ネットワークアクセスのためのファイアウォール機能を提供する、デバイス上で実行されソフトウェアである。例えば、ファイアウォールは、デバイス（例えば、コンピュータ、スマートフォン、または、他のタイプのネットワーク通信可能デバイス）のオペレーティングシステムの中へ統合することができる。ファイアウォールは、また、コンピュータサーバ、ゲートウェイ、ネットワーク／ルーティングデバイス（例えば、ネットワークルータ）、および、データ装置（例えば、セキュリティ装置または他のタイプの特殊目的のデバイス）上のソフトウェアとして、統合され、もしくは、実行することもできる。
【0009】
ファイアウォールは、典型的に、一式のルールに基づいてネットワーク送信を拒否または許可する。これら一式のルールは、しばしば、ポリシ（policy）として参照される。例えば、ファイアウォールは、望まれない（unwanted）外部トラフィックが保護されるデバイスに到達するのを妨げるために、一式のルールまたはポリシを適用することによって、インバウンドトラフィックをフィルタリングすることができる。ファイアウォールは、また、一式のルールまたはポリシ(例えば、許可、ブロック、モニタリング、通知またはログ、及び／又は、他のアクションは、ここにおいて説明されような、様々なクライテリアに基づいて、トリガされ得る、ファイアウォールルールまたはファイアウォールポリシにおいて指定することができる)を適用して、アウトバウンドトラフィック（outbound traffic）をフィルタリングすることもできる。ファイアウォールは、また、一式のルールまたはポリシを同様に適用することによって、ローカルネットワーク(例えば、イントラネット)トラフィックをフィルタリングすることもできる。
【0010】
セキュリティデバイス(例えば、セキュリティ装置、セキュリティゲートウェイ、セキュリティサービス、他のセキュリティデバイス)は、様々なセキュリティ機能(例えば、ファイアウォール、マルウェア対策、侵入防止/検出、データ損失防止(DLP)、及び／又は、他のセキュリティ機能)、ネットワーク機能(例えば、ルーティング、クオリティ・オブ・サービス(QoS)、ネットワーク関連リソースのワークロードバランス、他のネットワーク機能)、及び／又は、他の機能を含むことができる。例えば、ルーティング機能は、送信元情報(例えば、IPアドレスとポート)、宛先情報(例えば、IPアドレスとポート)、および、プロトコル情報に基づくことができる。
【0011】
基本的パケットフィルタリングファイアウォールは、ネットワーク(例えば、ステートレスパケットフィルタリングファイアウォールである、パケットフィルタリングファイアウォールまたは第一世代ファイアウォール)を介して送信される個々のパケットを検査することによって、ネットワーク通信トラフィックをフィルタリングする。ステートレスパケットフィルタリングファイアウォールは、典型的に、個々のパケット自体を検査し、そして、検査されたパケットに基づいて、ルールを適用する(例えば、パケットの送信元と宛先のアドレス情報、プロトコル情報、および、ポート番号の組み合わせを使用する)。
【0012】
アプリケーションファイアウォールは、また、アプリケーション層フィルタリング(例えば、TCP/IPスタックのアプリケーションレベルで動作する、アプリケーション層フィルタリングファイアウォールまたは第二世代ファイアウォール)を実行することもできる。アプリケーション層フィルタリングファイアウォールまたはアプリケーションファイアウォールは、一般的に、所定のアプリケーションおよびプロトコル(例えば、ハイパーテキスト転送プロトコル(HTTP)を使用したWebブラウジング、ドメインネームシステム(DNS)要求、ファイル転送プロトコル(FTP)を使用したファイル転送、および、Telnet、DHCP、TCP、UDP、およびTFTP(GSS)などの他の様々なタイプのアプリケーションや他のプロトコル)を識別することができる。例えば、アプリケーションファイアウォールは、標準ポートを介して通信しようとする不正なプロトコルをブロックできる(例えば、そのプロトコルの非標準ポートを使用して忍び込もうとしている無許可/ポリシ外のプロトコルは、一般的に、アプリケーションファイアウォールを使用して識別することができる)。
【0013】
ステートフルファイアウォールは、また、状態ベースのパケット検査を実行することもでき、この検査では、各パケットが、そのネットワーク伝送のパケットフローに関連付けられた一式のパケットのコンテキスト内で検査される。このファイアウォール技法は、ファイアウォールを通過する全ての接続の記録を保持し、かつ、パケットが新しい接続の開始であるか、既存の接続の一部であるか、または、無効なパケットであるかを判断できるため、一般的に、ステートフルパケット検査と称される。例えば、接続の状態自体が、ポリシ内のルールをトリガするクライテリアの１つになり得る。
【0014】
先進または次世代ファイアウォールは、上述のように、ステートレスおよびステートフルパケットフィルタリングおよびアプリケーション層フィルタリングを実行することができる。次世代ファイアウォールは、追加的なファイアウォール技法を実行することもできる。例えば、先進ファイアウォールまたは次世代ファイアウォールとして、ときどき、称される所定の新しいファイアウォールは、ユーザおよびコンテンツ(例えば、次世代ファイアウォール)を識別することもできる。特に、所定の次世代ファイアウォールは、これらのファイアウォールが自動的に識別できるアプリケーションのリストを数千のアプリケーションに拡大している。そうした次世代ファイアウォールの例は、パルアルトネットワークス社から市販されている(例えば、パルアルトネットワークス社のPAシリーズファイアウォール)。例えば、パルアルトネットワークス社の次世代ファイアウォールは、企業が、様々な識別テクノロジーを使用して、－ポート、IPアドレス、およびパケットだけでなく－アプリケーション、ユーザ、およびコンテンツを識別および制御するのを可能にする。正確なアプリケーション識別のためのAPP-ID、ユーザ識別(例えば、ユーザまたはユーザグループ)のためのUser-ID、リアルタイムコンテンツスキャン(例えば、ウェブサーフィンの制御およびデータやファイル転送の制限)のためのContent-ID、といったものである。これらの識別テクノロジーにより、企業は、従来のポートブロックファイアウォールによって提供される従来のアプローチに従う代わりに、ビジネスに関連する概念を使用してアプリケーションの使用をセキュアに可能にする。また、次世代ファイアウォール用の特殊目的ハードウェア(専用装置などとして実装されているもの)は、一般的に、アプリケーション検査について、汎用ハードウェアにおいて実行されるソフトウェアよりも高いパフォーマンスレベルを提供する(例えば、パルアルトネットワークス社が提供するセキュリティ装置といったものであり、シングルパスソフトウェアエンジンと緊密に統合された専用の、機能固有の処理を使用し、ネットワークスループットを最大化し、一方で、レイテンシを最小限に抑えている)。
【0015】
高度または次世代のファイアウォールは、また、仮想化ファイアウォールを使用して実装することもできる。そうした次世代ファイアウォールの例は、パルアルトネットワークス社から市販されている(例えば、パルアルトネットワークスのVMシリーズファイアウォールであり、例として、VMware(R)ESXiTMとNSXTM、Citrix(R)Netscaler SDXTM、KVM/OpenStack(Centos/RHEL、Ubuntu(R))、Amazon Web Services(AWS)を含む、様々な商用仮想化環境をサポートしている)。例えば、仮想化ファイアウォールは、類似または全く同じ次世代ファイアウォール、および、物理的なフォームファクタの装置で使用可能な高度な脅威防止機能をサポートすることができ、企業は、自身のプライベート、パブリック、およびハイブリッドのクラウドコンピューティング環境の中へ、または、環境にわたり、アプリケーションの実行をセキュアに可能にする。VMモニタリング、ダイナミックアドレスグループ、およびRESTベースのAPIといった自動化機能により、企業は、VMの変更を積極的に（proactively）モニタリングすることができ、そのコンテキストを動的に（dynamically）セキュリティポリシの中へ取り込に、それによって、VMの変更時に発生し得るポリシの遅延（policy lag）を排除している。
【0016】
II.例示的な環境（EXAMPLE ENVIRONMENT）
【0017】
図1は、悪意のあるアクティビティが検出され、その害が軽減される環境の一例を示している。図1に示されている例において、クライアントデバイス104-108は、病院(「アクメ病院（“Acme Hospital”）」とも称される)のエンタープライズネットワーク110内に(それぞれに)存在する、ラップトップコンピュータ、デスクトップコンピュータ、およびタブレットである。データ装置102は、クライアントデバイス104および106といった、クライアントデバイスと、エンタープライズネットワーク110の外部のノード(例えば、外部ネットワーク118を介して到達可能なもの)との間の通信に関するポリシを実行するように構成されている。
【0018】
そうしたポリシの例は、トラフィックシェーピング、クオリティ・オブ・サービス、およびトラフィックのルーティングを制御する（governing）ポリシを含む。他のポリシの例は、着信(及び／又は発信)電子メールの添付ファイル、Webサイトのコンテンツ、インスタントメッセージングプログラムを通じて交換されるファイル、及び／又は、他のファイル転送における脅威についてスキャンを必要とするポリシといった、セキュリティポリシを含む。いくつかの実施例において、データ装置102は、また、エンタープライズネットワーク110内に留まるトラフィックに関してポリシを実行するようにも構成されている。
【0019】
ネットワーク110は、また、ディレクトリサービス154、および、Authentication,Autorization,and Accounting（AAA)サーバ156も含んでいる。図1に示される例において、ディレクトリサービス154(Iアイデンティティプロバイダまたはドメインコントローラとも称されるもの)は、Lightweight Directory Access Protocol(LDAP)または他の適切なプロトコルを使用する。ディレクトリサービス154は、ユーザアイデンティティおよびクレデンシャル情報（credential information）を管理するように構成されている。ディレクトリサービス154の一例は、Microsoft Active Directoryサーバである。ケルベロスベース（Kerberos-based）システムといった、他のタイプのシステムも、また、Active Directoryサーバの代わりに使用することができ、ここで説明する技術はそれに応じて適応される。図1に示される例において、AAAサーバ156は、ネットワークアドミッションコントロール(NAC)サーバである。AAAサーバ156は、有線、無線、およびVPNのユーザとデバイスをネットワークに対して認証し、ネットワークへのアクセスを許可する以前にポリシコンプライアンスについてデバイスを評価および修復（remediate）し、ロールに基づいてアクセスを差別化し、そして、次いで、ネットワーク上に居る人を監査およびレポートするように構成されている。AAAサーバ156の一例は、Remote Authentication Dial-In User Service(RADIUS)を利用するCisco Identity Services Engine(ISE)サーバである。RADIUS以外のプロトコルを使用するものを含む、他のタイプのAAAサーバが、ここにおいて説明される技法と組み合わせて使用できる。
【0020】
様々な実施例において、データ装置102は、ディレクトリサービス154及び／又はAAAサーバ156に対する／からの通信を聞く（listen）するように構成されている(例えば、メッセージを受動的にモニタリングする)。様々な実施例において、データ装置102は、ディレクトリサービス154及び／又はAAAサーバ156と通信するように構成されている(すなわち、それらと積極的にメッセージをやり取りする)。様々な実施例において、データ装置102は、ディレクトリサービス154及び／又はAAAサーバ156といった様々なネットワーク要素と通信するオーケストレータ（orchestrator）（図示なし）と通信するように構成されている(例えば、と積極的にメッセージをやり取りする)。他のタイプのサーバも、また、ネットワーク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をモニタリングし、そして、開示される技法を実装する際に使用される情報を(RAM204、ストレージ210、及び／又は、他の適切な場所のいずれかに)保管する。そうした情報の例は、アプリケーション識別子、コンテンツ識別子、ユーザ識別子、要求されたURL、IPアドレスマッピング、ポリシ、および、他のコンフィグレーション情報、署名、ホスト名/URLカテゴリ化情報、マルウェアプロファイル、機械学習モデル、IoTデバイス分類情報、等を含んでいる。データ装置102は、また、１つ以上の任意的なハードウェアアクセラレータを含むこともできる。例えば、データ装置102は、暗号化および復号操作を実行するように構成された暗号化エンジン206、および、マッチングを実行し、ネットワークプロセッサとして機能し、かつ／あるいは、他のタスクを実行するように構成された１つ以上のフィールドプログラマブルゲートアレイ(FPGA)208を含むことができる。
【0024】
データ装置102によって実行されるものとして、ここにおいて説明される機能は、様々な方法で提供/実装することができる。例えば、データ装置102は、専用デバイスまたは一式のデバイスであってよい。所与のネットワーク環境は、複数のデータ装置を含んでよく、それぞれが、ネットワークの特定の部分にサービスを提供するように構成されてよく、ネットワークの特定の部分にサービスを提供するために協力することができる、等。
データ装置102によって提供される機能は、また、汎用コンピュータ、コンピュータサーバ、ゲートウェイ、及び／又は、ネットワーク/ルーティングデバイス上のソフトウェアとして統合され、または、実行することもできる。いくつかの実施形態において、データ装置102によって提供されるものとして説明される少なくともいくつかの機能性は、代わりに(または、追加的に)クライアントデバイス上で実行されるソフトウェアによってクライアントデバイス(例えば、クライアントデバイス104またはクライアントデバイス106)に提供される。データ装置102によって実行されるものとしてここにおいて説明されている機能性は、また、セキュリティプラットフォーム140によって、または、協働して、少なくとも部分的に実行することもでき、かつ／あるいは、セキュリティプラットフォーム140によって実行されるものとしてここにおいて説明されている機能性は、また、該当する場合、データ装置102によって、または、協働して、少なくとも部分的に実行することもできる。一例として、IoTモジュール138によって実行されるものと説明されている様々な機能は、IoTサーバ134の実施形態によって実行することができる。
データ装置102によって提供される機能は、また、汎用コンピュータ、コンピュータサーバ、ゲートウェイ、及び／又は、ネットワーク/ルーティングデバイス上のソフトウェアとして統合され、または、実行することもできる。いくつかの実施形態において、データ装置102によって提供されるものとして説明される少なくともいくつかの機能性は、代わりに(または、追加的に)クライアントデバイス上で実行されるソフトウェアによってクライアントデバイス(例えば、クライアントデバイス104またはクライアントデバイス106)に提供される。データ装置102によって実行されるものとしてここにおいて説明されている機能性は、また、セキュリティプラットフォーム140によって、または、協働して、少なくとも部分的に実行することもでき、かつ／あるいは、セキュリティプラットフォーム140によって実行されるものとしてここにおいて説明されている機能性は、また、該当する場合、データ装置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復号が、SSL復号エンジン220によって適用される。そうでなければ、SSL復号エンジン220による処理は省略される。復号エンジン220は、データ装置102がSSL/TLSおよびSSHで暗号化されたトラフィックを検査および制御するのを助けることができ、そして、従って、そうでなければ暗号化されたトラフィックに隠れて留まっている可能性のある脅威を阻止するのに役立つ。復号エンジン220は、また、機密性の高いコンテンツがエンタープライズネットワーク110から流出するのを防ぐのにも役立つ。復号は、URLカテゴリ、トラフィック送信元、トラフィック宛先、ユーザ、ユーザグループ、および、ポートといった、パラメータに基づいて選択的に制御できる(例えば、イネーブルまたはディセーブル)。復号ポリシ(例えば、復号するセッションを指定する)に加えて、ポリシによって制御されるセッションについて様々なオプションを制御するように、復号プロファイルを割り当てることができる。例えば、特定の暗号スイートおよび暗号化プロトコルバージョンの使用を要求することができる。
【0029】
アプリケーション識別(APP-ID)エンジン222は、何のタイプのトラフィックをセッションが含むかを判断するように構成されている。一例として、アプリケーション識別エンジン222は、受信したデータ内のGET要求を認識し、そして、セッションがHTTPデコーダを必要とすると結論付けることができる。場合によって、例えば、Webブラウジングセッションでは、識別されたアプリケーションが変更されることがあり、そして、そうした変更はデータ装置102によって記録される。例えば、ユーザは最初に企業のWikiを参照し(「Webブラウジング－生産性」として訪問したURLに基づいて分類される)、そして、次いで、それに続いて、ソーシャルネットワーキングサイトを参照することができる(「Webブラウジング－ソーシャルネットワーキング」として訪問したURLに基づいて分類される)。異なるタイプのプロトコルは、対応するデコーダを有している。
【0030】
アプリケーション識別エンジン222によって行われた判断に基づいて、パケットは、脅威エンジン224によって、パケット(順不同で受信され得るもの)を正しい順序に組み立て、トークン化を実行し、そして、情報を抽出するように構成されている、適切なデコーダに対して送信される。脅威エンジン224は、また、パケットに何が起こるかを判断するために、署名マッチングも実行する。必要に応じて、SSL暗号化エンジン226は、復号されたデータを再暗号化することができる。パケットは、(例えば、宛先への)送信のために、転送モジュール228を使用して転送される。
【0031】
また、図2Bにも示されるように、ポリシ232は、受信され、そして、管理プレーン212に保管される。ポリシは、ドメイン及び／又はホスト/サーバ名を使用して指定できる、１つ以上のルールを含むことができ、そして、ルールは１つ以上の署名、もしくは、他のマッチングクライテリアまたはヒューリスティック（heuristics）を適用することができる。モニタリングされるセッショントラフィックフローから抽出された様々なパラメータ/情報に基づいて、加入者/IPフローについてセキュリティポリシを実施するため、といったものである。インターフェイス(I/F)コミュニケータ230が、(例えば、(REST)API、メッセージ、もしくは、ネットワークプロトコル通信または他の通信メカニズムを介する)通信の管理のために提供される。ポリシ232は、また、IoTデバイスに関連する通信を管理するためのポリシを含むこともできる。
【0032】
III.IOTデバイスの検出と識別（IOT DEVICE DISCOVERY AND IDENTIFICATION）
【0033】
図1に戻り、悪意のある個人が(例えば、システム120を使用して)マルウェア130を作成したと仮定する。悪意のある個人は、脆弱なクライアントデバイスがマルウェア130のコピーを実行して、クライアントデバイスを侵害し、そして、クライアントデバイスをボットネットのボット（bot）にさせること、を期待している。侵害されたクライアントデバイスは、次いで、タスク(例えば、仮想通貨のマイニング、サービス拒否攻撃（denial of service attacks）への参加、および、他の脆弱なクライアントデバイスへの伝播)を実行し、そして、情報をレポートし、または、そうでなければ、外部のエンティティ(例えば、コマンド・アンド・コントロール（C&C）サーバ150)に対してデータを密かに抽出するように命じられ得る。該当する場合には、同様に、C&Cサーバ150から命令を受け取るように命じられる。
【0034】
図1に示されるいくつかのクライアントデバイスは、典型的に、企業組織内で使用されるコモディティコンピューティングデバイスである。例えば、クライアントデバイス104、106、および108は、それぞれ、典型的なオペレーティングシステム(例えば、macOS（登録商標）、Windows、Linux、Android、等)を実行する。そうしたコモディティコンピューティングデバイスは、しばしば、管理者によって(例えば、それぞれに、会社発行のラップトップ、デスクトップ、タブレットとして)提供され、かつ、メンテナンスされ、そして、しばしば、ユーザカウントと連携して操作される(例えば、ユーザIDおよびクレデンシャル情報で構成されたディレクトリサービスプロバイダ(ドメインコントローラとも称される)によって管理される)。一例として、従業員アリスは、自分のACME関連の電子メールにアクセスし、様々なACME関連のタスクを実行するために使用するラップトップ104を支給され得る。他のタイプのクライアントデバイス(ここでは一般的にモノのインターネットまたはIoTデバイスと称される)も、また、ネットワークに存在することが増えており、そして、しばしば、IT部門によって「管理されていない（“unmanaged”）」。そうしたデバイス(例えば、電話会議デバイス)は、様々な異なるタイプの企業にわたり(例えば、IoTホワイトボード144および146として)見い出されることがある。そうしたデバイスは、また、バーティカルスペシフィック（vertical specific）であり得る。例えば、輸液ポンプおよびコンピュータ断層撮影スキャナ(例えば、CTスキャナ112)は、ヘルスケアエンタープライズネットワーク(例えば、ネットワーク110)内で見い出され得るIoTデバイスの例であり、そして、ロボットアームは、製造エンタープライズネットワーク内で見い出され得るデバイスの例である。さらに、消費者指向のIoTデバイス(例えば、カメラ)も、また、エンタープライズネットワーク内に存在し得る。コモディティコンピューティングデバイスと同様に、ネットワーク内に存在するIoTデバイスは、そうしたネットワークの内部または外部にある(または、該当する場合には両方の)リソースと通信することができる。
【0035】
コモディティコンピューティングデバイスと同様に、IoTデバイスは、極悪な個人のターゲットである。残念なことに、ネットワーク内のIoTデバイスの存在は、いくつかの固有のセキュリティ/管理上の課題を提示し得る。IoTデバイスは、しばしば、低電力デバイスまたは特殊な目的のデバイスであり、そして、しばしば、ネットワーク管理者が知ることなく展開される。そうした管理者に知られている場合でさえも、IoTデバイスにエンドポイント保護ソフトウェアまたはエージェントをインストールできないことがある。IoTデバイスは、独自の(または、そうでなければ標準以外の)プロトコルを使用して、第三者のクラウドインフラストラクチャによって管理され、そして、単独で/直接的に通信し得る(例えば、産業用温度計152はクラウドインフラストラクチャ126と直接的に通信している)。これは、デバイスに対する脅威や攻撃がいつ発生しているかを判断するために、そうしたデバイスに出入りするネットワークトラフィックをモニタリングする試みを混乱させることがある。さらに、いくつかのIoTデバイスは(例えば、医療環境において)、ミッションクリティカルである(例えば、ネットワークに接続された外科システム)。残念ながら、IoTデバイスの侵害(例えば、マルウェア130によるもの)、または、IoTデバイスに関連するトラフィックに対するセキュリティポリシの誤った適用は、壊滅的な影響を及ぼす可能性がある。ここにおいて説明される技法を使用して、IoTデバイスを含む、異種ネットワークのセキュリティを向上させ、そして、そうしたネットワークに与える悪影響を軽減することができる。
【0036】
様々な実施例において、データ装置102は、IoTサーバ134を含んでいる。IoTサーバ134は、いくつかの実施例において、セキュリティプラットフォーム140のIoTモジュール138と協力して、ネットワーク(例えば、ネットワーク110)内のIoTデバイスを識別するように構成されている。そうした識別は、例えば、データ装置102によって、IoTデバイスに関連付けられたトラフィックに関するポリシの作成および実施を支援するため、そして、ネットワーク110の他の要素の機能を強化する(例えば、AAA156にコンテキスト情報を提供する)ために使用することができる。様々な実施形態において、IoTサーバ134は、トラフィックを受動的に嗅ぎ付け（sniff）/モニタリングするように構成された１つ以上のネットワークセンサを組み込んでいる。そうしたネットワークセンサ機能を提供する方法の一例は、タップインターフェイスまたはスイッチミラーポートとしてのものである。トラフィックをモニタリングするための他のアプローチも、また、該当する場合、(追加的または代わりに)使用することができる。
【0037】
様々な実施例において、IoTサーバ134は、IoTモジュール138に対して(例えば、フロントエンド142を介して)ログまたは他のデータ(例えば、モニタリングネットワーク110から受動的に収集されたもの)を提供するように構成されている。図2Cは、IoTサーバとIoTモジュールとの間のイベントパスの一例を示している。IoTサーバ134は、デバイス検出イベントおよびセッションイベントをIoTモジュール138に送信する。検出イベントおよびセッションイベントの一例が、それぞれに、図2Dおよび図2Eに示されている。様々な実施例においては、デバイスのアイデンティティを一意に識別または確認できるパケットを観測したときはいつでも(例えば、DHCP、UPNP、またはSMBパケットが観測されたときはいつでも)、IoTサーバ134によって検出イベントが送信される。デバイスが持つ各セッションは(デバイスのネットワークの内側または外側にかかわらず、他のノードとのもの)、セッションに関する情報を要約するセッションイベント内で記述される(例えば、送信元/宛先情報、受信/送信パケット数、等)。該当する場合、複数のセッションイベントは、IoTモジュール138に送信する前に、IoTサーバ134によって、一緒にバッチ処理され得る。図2Eに示される例には、2つのセッションが含まれている。IoTモジュール138は、デバイス判定（verdict）イベント(234)を介してIoTサーバ134にデバイス分類情報を提供する。
【0038】
IoTモジュール138を実装する方法の一例は、マイクロサービスベースのアーキテクチャを使用することである。IoTモジュール138は、また、該当する場合、異なるプログラミング言語、データベース、ハードウェア、ソフトウェア環境を使用して実装することもできる。かつ／あるいは、メッセージング（messaging）が、イネーブルされ、コンテキストによって制限され、自律的に開発され、独立して展開可能で、分散化され、そして、自動化されたプロセスで構築およびリリースされるサービスとしても実装され得る。IoTモジュール138によって実行されるタスクの１つは、IoTサーバ134によって提供され（そして、データ装置136と148といった、データ装置の他の実施形態によって提供される）データにおいてIoTデバイスを特定し、そして、それらのデバイスに関する148追加的なコンテキスト情報を(例えば、それぞれのデータ装置に戻り)提供することである。
【0039】
図2Fは、IoTモジュールの一実施形態を示している。リージョン294は、全てのテナントのデータにわたりインターバル(例えば、5分ごと、1時間ごと、毎日)で実行されるSparkアプリケーションのセットを示している。リージョン296は、Kafkaメッセージバスを示している。IoTモジュール138によって(例えば、IoTサーバ134から)受信したセッションイベントメッセージは、(例えば、帯域幅を節約するために)IoTサーバ134で観察された複数のイベントを一緒にバンドルする。変換モジュール236は、受信したセッションイベントを個々のイベントへとフラット化し、そして、250で公開（publish）するように構成されている。フラット化されたイベントは、様々な異なる集約ルールを使用して、集約モジュール238によって集約される。ルールの一例は、「時間インターバル(例えば、5分)について、特定のデバイス及びそれが使用した各(APP-ID)アプリケーションの全てのイベントデータを集計する」である。別のルールの例は、「時間インターバル(例えば、1時間)について、特定の宛先IPアドレスと通信する特定のデバイスの全てのイベントデータを集約する」である。各ルールについて、集約エンジン238は、集約される必要がある属性のリストを追跡する(例えば、デバイスによって使用されているアプリケーションのリスト、または、宛先IPアドレスのリスト)。特徴抽出モジュール240は、属性から特徴(252)を抽出する。分析モジュール242は、(例えば、教師あり学習および教師なし学習を使用して)デバイス分類を実行するために、抽出された特徴を使用し、その結果(254)は、他のタイプの分析を強化（power）するために(例えば、オペレーショナルインテリジェンスモジュール244、脅威分析モジュール246、および、異常検出モジュール248を介して)使用される。運用インテリジェンスモジュール244は、OTフレームワークに関連する分析、および、運用またはビジネスインテリジェンス(例えば、デバイスの使用方法)を提供する。分析の結果に基づいて、アラート(256)が生成され得る。様々な実施形態において、MongoDB 258は、集約されたデータおよび特徴値を保管するために使用されている。バックグラウンドサービス262は、Sparkアプリケーションによって集約されたデータを受信し、そして、データをMongoDB 258に書き込む。APIサーバ260は、フロントエンド142から受信した要求を取り扱う（serve）ために、MongoDB 258からデータをプル（pull）し、かつ、マージする。
【0040】
図2Gは、IoTデバイス識別分析の実装方法の一例を示している(例えば、分析モジュール242および関連要素の実装としてのIoTモジュール138におけるもの)。検出イベントおよびセッションイベントは(例えば、図2Dと図2Eに、それぞれ、示されるように)、Kafkaトピックとしてメッセージバス上で生データ264として受信される(そして、また、ストレージ158にも保管される)。特徴は、特徴エンジン276によって抽出される(それは、例えば、Spark/MapReducerを使用して実装され得る)。生データは、(例えば、送信元/宛先アドレスの)位置情報といった、セキュリティプラットフォーム140による追加的なコンテキスト情報で強化(266)されている（enriched）。メタデータ特徴抽出(268)の最中には、IPアドレスから時間インターバル中に送信されたパケットの数、時間インターバル中に特定のデバイスによって使用されたアプリケーションの数、および、時間インターバル中にデバイスによってコンタクトされたIPアドレスの数といった、特徴が構築される。特徴は、(例えば、JSON形式で)インライン分析エンジン272に対して(例えば、メッセージバス上で)リアルタイムで渡され、そして、(例えば、オフラインモデリング299の最中に)後続のクエリについて、(例えば、Apache Parquet/DataFrameといった適切な形式の特徴データベース270に)保管される。
【0041】
メタデータから構築された特徴に加えて、IoTモジュール138によって第２のタイプの特徴を構築することができ(274)、ここにおいては分析特徴と称される。分析特徴の例は、集計データを使用して、時系列データに基づいて、時間にわたり構築されるものである。分析特徴は、同様に、リアルタイムで分析エンジン272に渡され、そして、特徴データベース270に保管される。
【0042】
インライン分析エンジン272は、メッセージハンドラを介してメッセージバス上で特徴を受信する。実行されるタスクの１つは、アクティビティ分類(278)であり、受信した特徴値/セッション情報に基づいて、セッションに関連付けられたアクティビティ(ダウンロードされたファイル、ログイン/認証プロセス、また、ディスクバックアップアクティビティ、といったもの)を識別するように試み、そして、任意の適用可能なタグを添付する。アクティビティ分類278を実装する方法の１つは、畳み込みニューラルネットワークと組み合わせた、ニューラルネットワークベースの多層パーセプトロンを介している。
【0043】
アクティビティ分類の結果として、特定のデバイスが印刷アクティビティに関わっており(すなわち、印刷プロトコルを使用する)、かつ、HPが所有するリソースにも定期的にコンタクトしていると(例えば、HPのURLを呼び出し、かつ、それを使用してステータス情報を報告することにより、更新を確認するため)判断されたと仮定する。様々な実施例において、分類情報は、クラスタリングプロセス(教師なし)および予測プロセス(教師あり)の両方に渡される。いずれかのプロセスによって成功裡にデバイスの分類が結果として生じた場合、分類は、デバイスデータベース286に保管される。
【0044】
デバイスは、第１ステージのクラスタリングエンジン280によって、その属性および他の行為（behavior）パターンに基づいて、複数のクラスタ(例えば、プリンタのように動作し、HPデバイスのように動作する、等)へとクラスター化され得る。クラスタリングエンジン280を実装する１つの方法は、勾配ブースティングフレームワーク(例えば、xgb)を使用することである。第１ステージの分類子（classifier）は、以前には見られなかったが、既存の既知のデバイスに類似するデバイスを分類するために役立ち得る(例えば、サーモスタットの新しいベンダ（vendor）は、既知のサーモスタットと同様に動作するサーモスタット装置の販売を開始する)。
【0045】
図2Gに示されるように、アクティビティ分類情報も、また、一式の分類子282に対して提供され、そして、デバイスに提供された特徴に基づいて予測が実行される。２つの可能性が発生し得る。第１のシナリオにおいて、デバイスが既知のデバイスプロファイルと一致する(すなわち、信頼性の高いスコア)、高い可能性が存在すると判断される。そうである場合、デバイスに関する情報が第２ステージの分類子(284)に対して提供され、デバイスの識別に対して最終的な判定が行ない(例えば、提供された情報および追加の適用可能なコンテキスト情報を使用する)、そして、それに応じてデバイスデータベース286を更新する。第２ステージの分類子を実装する１つの方法は、勾配ブースティングフレームワークを使用することである。第２のシナリオでは、信頼度スコアが低いと仮定する(例えば、デバイスは50%の信頼度でHPプリンタとHPノートパソコンの両方に一致する)。このシナリオにおいては、分類子282によって判断された情報が、クラスタリングで使用可能な追加情報としてクラスタリングエンジン280に対して提供され得る。
【0046】
また、図2Gには、オフラインモデリングモジュール299も示されている。オフラインモデリングモジュール299は、時間の制約がないため、インライン分析エンジン272と対比される(一方で、インライン分析エンジン272は、リアルタイムでデバイス分類情報を(例えばメッセージ234として)提供しようとする)。定期的(例えば、1日に1回または週に1回)に、(例えば、Pythonを使って実装されている)オフラインモデリングモジュール299は、インライン分析モジュール272によって使用されるモデルを再構築する。アクティビティモデリングエンジン288は、アクティビティ分類子278に対するモデルを構築し、それは、また、インライン分析の最中にデバイス識別のために分類子によって使用されるデバイスタイプモデル(296)にも使用される。ベースラインモデリングエンジン290は、デバイスモデルのベースライン行為のモデルを構築し、それは、また、特定のタイプのデバイス異常(292)、および、キルチェーン（kill chain）といった、特定のタイプの脅威(294)をモデル化するときにも使用される。生成されたモデルは、様々な実施形態において、モデルデータベース298に保管される。
【0047】
IV.ネットワークエンティティID AAA
【0048】
上述のように、アリスは、ACMEによってラップトップ104を支給されたと仮定する。ネットワーク110の様々なコンポーネントは、アリスが様々なリソースにアクセスするために使用する際に、連携してアリスのラップトップを認証する。一例として、アリスがラップトップ104をネットワーク110内に置かれたワイヤレスアクセスポイント(図示なし)に接続するとき、ワイヤレスアクセスポイントは、ネットワークアクセスをプロビジョニングする一方で、AAAサーバ156と（直接的または間接的に)通信することができる。別の例として、アリスがACMEの電子メールにアクセスするためにラップトップ104を使用するとき、ラップトップ104は、彼女の受信トレイをフェッチする一方で、ディレクトリサービス154と(直接的または間接的に)通信することができる、等。コモディティのオペレーティングシステムを実行しているコモディティのラップトップとして、ラップトップ104は、適切なAAAメッセージ(例えば、RADIUSクライアントメッセージ)を生成することができ、それは、ラップトップ104が、必要とする適切なリソースに対するアクセスを得るのに役立つ。
【0049】
上述のように、110といったネットワーク内のIoTデバイス(例えば、デバイス146)によってもたらされる１つの問題は、そうしたデバイスが、しばしば、「管理されていない（“unmanaged”）」(例えば、ネットワーク管理者によって設定されていない、プロビジョニングされていない、管理されてない、等)であり、RADIUSといったプロトコルをサポートしておらず、そして、従って、ラップトップ104といった他のデバイスのようなAAAサービスと統合できないことである。IoTデバイスにネットワーク110内のネットワークアクセスを提供するために、様々なアプローチを採用することができるが、それぞれに欠点がある。１つのオプションは、ACMEについて、IoTデバイスがゲストネットワークを(例えば、事前共有キーを介して)使用するように制限することである。残念ながら、このことは、IoTデバイスが合法的にアクセスを有するべきであるネットワーク110内の他のノードと通信することができない場合に、IoTデバイスのユーティリティを制限し得る。別のオプションは、IoTデバイスがネットワーク110に無制限にアクセスできるようにすることであるが、セグメント化されたネットワークを有することのセキュリティ上のメリットを軽減している。さらに別の方法は、所与のIoTデバイスがどのようにネットワーク110内のリソースにアクセスできるかを管理するルールを、ACMEが手動で指定することである。このアプローチは、一般的に様々な理由で支持されず/実行することできない。一例として、管理者は、しばしば、IoTデバイスの展開に関与していないことがあり、そして、従って、そうしたデバイスに対するポリシが(例えば、データ装置102内に)含まれるべきであることを知らないことがある。管理者が、(例えば、デバイス112といったデバイスについて)装置102において特定のIoTデバイスについてポリシを手動で設定した場合でも、そうしたポリシを最新の状態に保つことはエラーが発生しやすく、そして、ネットワーク110に存在し得るIoTデバイスの数が非常に多いことを考えると、一般的に受け入れられない。さらに、そうしたポリシは単純化されている可能性が高く(例えば、CTスキャナ112をIPアドレス及び／又はMACアドレスによって特定のネットワークに割り当てる)、そして、CTスキャナ112に関連する接続/ポリシについてより細かく制御することはできない(例えば、外科用デバイスとPOS（point of sales）端末に適用されるポリシを動的に含むこと)。さらに、CTスキャナ112が手動でデータ装置102に含まれている場合でさえも、上述のように、IoTデバイスは、一般的にRADIUSなどのテクノロジーをサポートしておらず、そして、そうした技法をより完全にサポートしている他のタイプのデバイス(例えば、ラップトップ104)と比較して、そうしたAAAサーバでCTスキャナ112のネットワークアクセスを管理する利点は制限されている。以下で、より詳細に説明されるように、様々な実施形態において、データ装置102は(例えば、IoTサーバ134経由を介して)、ネットワーク110内に存在するIoTデバイスにAAA機能のサポートを受動的な方法で提供するように構成されている。
【0050】
次の説明では、ACMEにおけるアリスの部署が最近インタラクティブホワイトボード146を購入し、その結果、アリスが、他のACMEの従業員並びにACME以外の個人(例えば、独自のネットワーク114、データ装置136、ホワイトボード144を持つベータ大学の研究者である、ボブ)と協働できるようになったと仮定する。ホワイトボード146の初期設定の一部として、アリスは、ホワイトボードを電源に接続し、そして、有線接続(例えば、会議室のコンセントに)、または、無線クレデンシャル(例えば、会議室のビジターによる使用のためのクレデンシャル)を提供する。ホワイトボード146がネットワーク接続をプロビジョニングすると、IoTサーバ134は、(例えば、上述のようにネットワークセンサといったメカニズムを介して)ホワイトボード146を、ネットワーク110内の新しいデバイスとして認識する。この検出に応じてとられる１つのアクションは、セキュリティプラットフォーム140と通信することである(例えば、データベース160内にホワイトボード146について新しいレコードを作成し、そして、ホワイトボード146に関連する現在利用可能なコンテキスト情報を取得する(例えば、ホワイトボード146の製造元、ホワイトボード146のモデル、等を得ること))。セキュリティプラットフォーム140によって提供される任意のコンテキスト情報は、データ装置102に提供(および保管)することができ、データ装置は、次いで、該当する場合、ディレクトリサービス154及び／又はAAAサーバ156に対して提供することができる。該当する場合、IoTモジュール138は、ホワイトボード146に関する更新されたコンテキスト情報を、利用可能になった際に、データ装置102に提供することができる。そして、データ装置102は、(例えば、IoTサーバ134を介して)同様に、ホワイトボード146に関する継続的な情報をセキュリティプラットフォーム140に提供できる。そうした情報の例は、ネットワーク110でのホワイトボード146の行為に関する観察(例えば、接続に関する統計情報)を含み、それは、セキュリティプラットフォーム140によって、ホワイトボード146といったデバイスの行為プロファイルを構築するために使用することができる。同様の行為プロファイルは、他のデバイス(例えば、ホワイトボード144)に対するセキュリティプラットフォーム140によって構築され得る。そうしたプロファイルは、異常な行為を検出することを含み、様々な目的のために使用され得る。一例として、データ装置148は、セキュリティプラットフォーム140によって提供される情報を使用して、温度計152が、温度計152の履歴観測と比較して、かつ／あるいは、類似のモデル、製造元、または他のネットワークに存在する温度計を含む、より一般的な他の温度計（図示なし）と比較して、異常な行為をしているか否かを検出できる。異常な行為が(例えば、データ装置148によって)検出された場合には、適切な修復アクションが自動的に実行され得る。ネットワーク116上の他のノードに対する温度計152のアクセスを制限すること、アラートを生成すること、等といったものである。
【0051】
図3は、ネットワーク内のIoTデバイスに対してAAAサポートを受動的に提供するプロセスの一実施形態を示している。様々な実施形態において、プロセス300は、IoTサーバ134によって実行される。本プロセスは、IoTデバイスによって送信された一式のパケットが取得されたときに302で開始される。一例として、ホワイトボード146がネットワーク110において最初にプロビジョニングされたとき、そうしたパケットは、302でIoTサーバ134によって受動的に受信され得る。その後のホワイトボード146の使用の最中にも、(例えば、アリスがホワイトボード144を介してボブとホワイトボードセッションを行っている際に)パケットは、また、302で受動的に受信され得る。304では、データパケットのセットに含まれる少なくとも１つのパケットが、分析される。304で実行される処理の一例として、IoTサーバ134は、302で受信したパケットがホワイトボード146によって送信されているものと判断する。IoTサーバ134が実行できる１つのアクションは、ホワイトボード146をネットワーク110上の新しいIoTデバイスとして識別し、そして、利用可能であれば、IoTモジュール138からコンテキスト情報を取得することである。306において、IoTサーバ134は、IoTデバイスの代わりに、IoTデバイスに関連付けられた情報を含むAAAメッセージを送信する。そうしたメッセージの一例が図4Aに示されている。上述のように、ホワイトボード146はRADIUSプロトコルをサポートしていない。しかしながら、IoTサーバ134は、ホワイトボード146の代わりに、図4Aに示されるようなメッセージを(例えば、302で受信した情報、および、該当する場合には、セキュリティプラットフォーム140から受信した情報も使用して)生成することができる。上述のように、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は、一旦ホワイトボード146に関するコンテキスト情報(例えば、様々なIoTデバイスに関するコンテキスト情報のデータベースを含んでいるもの)がIoTモジュール138によって提供されると、ホワイトボード146の代わりにIoTサーバ134が送信することができる、RADIUSメッセージの一例を示している。図4Bに示される例においては、ホワイトボードの製造元(パナソニック)およびやデバイスの性質(例えば、インタラクティブなホワイトボードであること)といったコンテキスト情報が含まれている。そうしたコンテキスト情報は、AAAサーバ156といったAAAサーバによって(ホワイトボード146を変更する必要なく)、ホワイトボード146に対してAAAサービスを提供するために使用され得る。テレビ会議機器専用のサブネットワークに自動的にプロビジョニングすることによる、といったものである。他のタイプのIoTデバイスも、また、デバイスタイプ、目的、等の属性に基づいて、自動的にグループ化され得る(例えば、重要な手術機器は、そうした機器専用のサブネットワークに自動的にプロビジョニングされ、そして、従って、ネットワークにおいて他のデバイスから分離されている)。トラフィックシェーピング（shaping）ポリシといったポリシを強化するために、そうしたコンテキスト情報が使用され得る。(例えば、APP-IDを使用して決定されるように)、ソーシャルネットワーキングパケットにわたりホワイトボード146パケットに対して優先的な取り扱いを与えるポリシ、といったものである。きめ細かいポリシが、同様に、重要な手術機器との通信に対して適用することができる(例えば、そうした機器と通信している機器のOSが期限切れになるのを防ぐこと)。図4Cに示される例においては、ホワイトボード146の代わりに、IoTサーバ134によって、さらに多くのコンテキスト情報がRADIUSメッセージ内に含まれている。そうした追加のコンテキスト情報は、デバイスモデル、オペレーティングシステム、およびオペレーティングバージョンといった追加的な属性情報を含んでいる。ホワイトボード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メッセージを生成することができる。一例として、ホワイトボード146からのトラフィックが最初に観察されたときに、RADIUSアカウンティング開始メッセージをトリガすることができる。ホワイトボードの使用中に、定期的なRADIUSアカウンティング中間更新メッセージを送信することができ、そして、ホワイトボード146がオフラインになったときに、RADIUSアカウンティング停止メッセージを送信することができる。
【0053】
V.統計的ペイロードフィンガープリントを使用したIOTデバイス識別の自動化
【0054】
上述のように、セキュリティプラットフォーム140は、様々なタイプのIoTデバイスを識別するために使用可能な様々な情報を(例えば、データベース160内に)維持している。いくつかのデバイス(例えば、コモディティ消費者向け商品)は、共通のプロトコル/アプリケーションを利用し、そして、そうした情報を使用して(例えば、セキュリティプラットフォーム140によって)容易に識別され得る。そうしたデバイスの例は、プリンタ、カメラ、サーモスタット、および清掃ロボットを含んでいる。別の例として、放射線医学デバイスは、典型的に、Digital Imaging and Communications in Medicine(DICOM)として知られるような、十分に文書化された非プロプライエタリ（non-proprietary）なデータ交換プロトコルを使用する。様々な実施形態において、IoTサーバ134(または、該当する場合、他の要素)は、DICOMデコーダを含んでおり、それは、DICOMトラフィックをデコーディングし、そして、所定の放射線医学デバイスの識別に使用可能な、様々な属性(例えば、製造元識別子、DICOM実装バージョン、等)を抽出することができる。
【0055】
残念ながら、いくつかのIoTデバイスは、独自のネットワークプロトコルおよびアプリケーションといった、独自技術を使用しており、それは、識別を行うことをより困難にし得る。医療業界におけるそうしたデバイスの例は、患者モニタリング、ナースコールシステム、薬剤調剤システム、バイタルサインモニタリング、および遠隔医療ロボットを含んでいる。産業および製造業界におけるそうしたデバイスの例は、プログラマブルロジックコントローラ、自動誘導車両、半導体製造装置、およびロボットアームを含んでいる。いくつかの特殊なデバイスは、標準的なプロトコルおよびアプリケーションを使用し得るが、一方で、他の者は、セキュリティプラットフォーム140によって理解されないプロトコルを使用することもある。様々な実施形態において、セキュリティプラットフォーム140は、それにもかかわらず、そうしたデバイスを分類し、そして、データ装置102といったデータ装置が、そうしたデバイスに関してポリシを実施できるようにすることができる。
【0056】
ネットワークトラフィックの所与のバイト(8ビットを含んでいる)は、0から255までの値を有する。異なるタイプのデバイスは、異なるアプリケーションを使用し、それは、しばしば、頻繁に使用されるバイトのユニークなセットを有している。場合によっては、トラフィックに係る根底にある意味を理解することなく、様々なタイプのデバイスのトラフィックを区別するために、バイト頻度に関する情報を使用することができる。
【0057】
デバイス上で実行される各アプリケーションは、対応するフローを有して庵、それは、データ装置によって観察することができる(例えば、TCPフローまたはUDPフローがデータ装置102によって観察される)。一つの例示的な実施形態にでは、各フローについて、IoTサーバ134は、ペイロードにおけるバイトを、それらが観察される際に追跡する(例えば、アレイ内の0-255バイトそれぞれについて適用可能なカウントをインクリメントする)。そうしたデータを保管する方法の例は、(各デバイスについて)２次元アレイとしてのものであり、ここでは、第１の最初の次元はフロー識別子であり、そして、第２の次元は0-255のバイト値である。トランスポート層において、フローは、5個のタプル（tuple）によって一意に識別できる。<src_ip、src_port、dst_ip、dst_port、prot>である。ここで、src_ipは送信元IPアドレスであり、src_portは送信元ポート番号であり、dst_ipは宛先IPアドレスであり、dst_portは宛先ポート番号であり、そして、protはプロトコル番号である。一意の5個のタプルそれぞれを整数フロー（integer flow）識別子にマップするために、ハッシュテーブルを使用することができる。パケットが到着すると、トランスポート層ヘッダー内の5個のタプルを使用してハッシュテーブルを調べ（look up）し、フロー識別子が存在する場合はそれを見つけ、または、そうでなければ、新しいものを作成する。フロー識別子を決定した後で、対応するバイト頻度は、(図5Aに示されるように)パケット内のペイロードに基づいて更新される。ハッシュテーブルの各エントリは、また、フローに対して処理されてきたパケット数を示すフィールドも有している。
【0058】
いくつかの実施例において、(例えば、IoTサーバ134によって)生バイトカウントが、セキュリティプラットフォーム140に対して(例えば、デバイスのMACアドレスおよび他の情報と一緒に)に報告される。そうしたレポートの一例が（JSON形式で)図5Bに示されている。バイトカウントは、フローの終了時にレポートされ、そして、また、(例えば、オーバーヘッドを低減するために)フローの終了前にレポートすることもできる。多くのアプリケーションについて、最初のnパケット(例えば、10パケット)は、最もユニークなアプリケーション固有またはプロトコル固有の情報を含んでおり、そして、フロー全体が分析される必要がない。様々な実施例において、セキュリティプラットフォーム140は、受信したバイトカウント情報を使用して、ネットワーク110内のデバイスについてバイト頻度分布(BFD)を決定し、それは、(例えば、所与のデバイスのBFDをデータベース160に保管されている情報と比較することによって)デバイスを自動的に分類するために使用することができる。前に説明したように、様々な実施例において、図1に示されている環境の他のコンポーネントは、そうした機能および適応される技法を、該当する場合、様々に実行することができる。一例として、いくつかの実施態様において、BFDは、セキュリティプラットフォーム140で決定されるのではなく、IoTサーバ134によってローカルに決定され、そして、セキュリティプラットフォーム140に送信される。
【0059】
図6A－図6Cは、3個のデバイスについて、それぞれに、バイト頻度分布(BFD)の例を示している。Carefusion輸液ポンプ、Rocheポイントオブケア（Point of Care、PoC)アナライザ、GE心電図(ECG)マシンである。図6A－図6Cそれぞれにおけるx軸は、0-255のバイト値を示している。図6A－図6Cそれぞれのy軸は、該当するバイト値を含んでいる観測されたフローの割合である。例えば、ポイント(128、0.01)は、観測されたトラフィックにおける全てのバイトのうち1%が0x80(バイト値128)であることを示している。
【0060】
図7は、IoTデバイスを分類するためのプロセスの一例を示している。様々な実施形態において、プロセス700は、セキュリティプラットフォーム140によって実行される。プロセス700は、また、該当する場合、他のシステムによって実行することもできる(例えば、IoTデバイスとオンプレミスでシステムが配置されている)。プロセス700は、IoTデバイスのネットワークトラフィックに関連付けられたバイト頻度パターンを受信したときに、702で開始される。一例として、プロセス700の部分702は、IoTサーバ134の実施形態がBFDをセキュリティプラットフォーム140に送信するときに発生する。別の例として、プロセス700の部分702は、セキュリティプラットフォーム140が(例えば、IoTサーバ134からのメッセージ500受信の応答として)BFDを生成または更新するときに発生する。
【0061】
704では、IoTデバイスについて分類を決定するために、受信したパターンが使用される。この決定を実行するために、様々なアプローチを使用することができる。第１の例として、パターンを、以前に決定されたパターン(例えば、データベース160に保管されており、かつ、既知のデバイスの観測から生成されるプロファイル)のライブラリに対して比較することができる。受信したパターンが、以前に保管されたプロファイルと閾値内で一致した場合には、それに応じて、IoTデバイスを分類することができる。複数の特徴を考慮することによって、精度を向上させることができる。一例として、受信したBFDが以前に保管されたライブラリプロファイルと一致するか否かを判断するときには、任意の利用可能な静的特徴(organizationally unique identifier（OUI)といったもの)を考慮することができる。このシナリオでは、例えば、BFDが閾値内のライブラリプロファイルと一致し、かつ、デバイスのOUIがライブラリプロファイルに関連付けられたOUIと一致する、両方である場合に、デバイスは、704で、特定のブランドの輸液ポンプとしてのみ分類される。さらに、プロセス700の部分702/704は、複数回発生し得る。例えば、デバイスが最初にネットワークに追加されたとき、デバイスが、そのアプリケーションを包括的に使用し、そして、そのバイト頻度パターンがその通信を代表するまでに、しばらく時間がかかることがある(例えば、数時間または数日)。704で、分類の一致が最初に見つからない場合に、プロセスは、更新されたBFDを用いて定期的に繰り返すことができる。
【0062】
様々な実施形態においては、704で、機械学習アプローチが使用される。一例として、いくつかの実施形態において、IoTモジュール138は、複数クラス分類のためにフィードフォワードニューラルネットワークを使用する機械学習デバイス識別エンジンを含んでいる。これは、プロファイルレベルのデバイス識別のための教師あり学習、並びに、さらなる研究のためにデバイスを異なるカテゴリへと分類する教師なし学習の両方をサポートしている。教師あり学習の場合、モデルをトレーニングするためにラベル付きデータ(すなわち、デバイス及びそれに対応する機能に係る既知のプロファイル)が提供される。次に、モデルは、(各バイト頻度パーセントに対応する256個の特徴を含む)特徴に基づいて、新しいデバイスのプロファイルを予測する。以下は、ネットワークトラフィックのメタデータから抽出し、そして、モデリングに含めることができる、追加的な機能の例である。合計バイトカウント、合計パケットカウント、合計セッションカウント、合計セッション時間、サーバポート番号、アプリケーションリスト、暗号化バイトカウント、リモートIPリスト、ダウンロードペイロードバイトカウント、HTTP要求カウント、HTTP応答カウント、TCP SYNカウント、およびTCP ACKカウント、である。教師なし学習の場合、デバイスは、その特徴に基づいて、不明なプロファイルを有するカテゴリに分類される。さらなる研究が、カテゴリ内のデバイスのプロファイルレベルのアイデンティティを明らかにした場合、その情報は、同じカテゴリ内の全てのデバイスを識別するために使用することができる。
【0063】
最後に、706では、704で決定された分類が、IoTデバイスにポリシを適用するように構成されたセキュリティ装置に対して提供される。上述のように、これにより、非常に細かい粒度のセキュリティポリシを、最小限の管理作業を用いてミッションクリティカルな可能性のある環境において実装することができる。該当する場合、セキュリティプラットフォーム140は、704で決定された分類に基づいて、特定のポリシを推奨することができる。以下は、実施できるポリシの例である。
【0064】
*全ての輸液ポンプのインターネットトラフィックを拒否する(ベンダに関係なく)。
【0065】
*所定のGEホストとの間を除いて、全てのGE ECGマシンのインターネットトラフィックを拒否する。
【0066】
*全てのCTスキャナに対して医療用画像管理システム（Picture Archiving and Communication System、PACS）サーバへの内部トラフィックのみを許可する(ベンダに関係なく)。
【0067】
上記の実施形態は、理解を明確にするためにある程度詳細に説明されているが、本発明は、提供される詳細に限定されるものではない。本発明を実施する多くの代替方法が存在している。開示された実施形態は、例示的なものであり、そして、限定的なものではない。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図2F】
【図2G】
【図3】
【図4A】
【図4B】
【図4C】
【図5A】
【図5B】
【図6A】
【図6B】
【図6C】
【図7】