知財求人 - 知財ポータルサイト「IP Force」
▶ パロ アルト ネットワークス，インコーポレイテッドの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-10-23
(54)【発明の名称】ファイアウォールにおけるＩｏＴセキュリティポリシ
(51)【国際特許分類】
G06F 21/57 20130101AFI20241016BHJP
【ＦＩ】
G06F21/57
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024513714
(86)(22)【出願日】2022-09-28
(85)【翻訳文提出日】2024-04-19
(86)【国際出願番号】 US2022045113
(87)【国際公開番号】W WO2023055851
(87)【国際公開日】2023-04-06
(31)【優先権主張番号】17/489,159
(32)【優先日】2021-09-29
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
２．ＰＹＴＨＯＮ
３．ＡＮＤＲＯＩＤ
４．ＸＢＯＸ
(71)【出願人】
【識別番号】517392861
【氏名又は名称】パロ アルト ネットワークス，インコーポレイテッド
【氏名又は名称原語表記】Ｐａｌｏ Ａｌｔｏ Ｎｅｔｗｏｒｋｓ，Ｉｎｃ．
【住所又は居所原語表記】３０００ Ｔａｎｎｅｒｙ Ｗａｙ，Ｓａｎｔａ Ｃｌａｒａ，Ｃａｌｉｆｏｒｎｉａ ９５０５４，Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100229448
【弁理士】
【氏名又は名称】中槇 利明
(72)【発明者】
【氏名】シッダム，カリアン
(72)【発明者】
【氏名】ドゥ，ジュン
(57)【要約】
モノのインターネット(IoT)デバイス通信においてポリシを実施するための技法が開示される。IoTデバイスのネットワーク通信に関連付けられた情報が受信される。受信された情報は、IoTデバイスに関連付けるために、デバイスタイプを含む、デバイスプロファイルを決定するために使用される。セキュリティ機器によって、IoTデバイスに適用されるべき推奨セキュリティポリシが生成される。
【特許請求の範囲】
【請求項1】
プロセッサおよびメモリを備える、システムであって、前記プロセッサは、
モノのインターネット(IoT)デバイスのネットワーク通信に関連付けられた情報を受信し、
前記IoTデバイスに関連付けるために、デバイスタイプを含む、デバイスプロファイルを決定するように、前記受信した情報を使用し、かつ、
前記デバイスプロファイルに少なくとも部分的に基づいて、セキュリティ機器によって前記IoTデバイスに適用されるべき推奨セキュリティポリシを生成する、
ように構成されており、
前記メモリは、
前記プロセッサに結合されており、かつ、前記プロセッサに命令を提供するように構成されている、
システム。
【請求項2】
前記プロセッサは、さらに、前記IoTデバイスが以前に分類されたか否かを決定する、ように構成されている、
請求項１に記載のシステム。
【請求項3】
前記プロセッサは、さらに、前記IoTデバイスが以前に分類されていなかったと決定したことに応答して、分類プロセスを実行する、ように構成されている、
請求項２に記載のシステム。
【請求項4】
前記分類プロセスを実行することは、インライン分類および前記インライン分類の後続の検証を、実行すること、を含む、請求項３に記載のシステム。
【請求項5】
前記プロセッサは、さらに、前記セキュリティポリシを適用するために、前記セキュリティ機器によって使用可能な命令を生成する、ように構成されている、
請求項１に記載のシステム。
【請求項6】
前記命令を生成することは、前記セキュリティポリシをベンダー固有の命令へと変換すること、を含む、請求項５に記載のシステム。
【請求項7】
前記情報は、前記セキュリティ機器から受信される、請求項１に記載のシステム。
【請求項8】
前記受信した情報は、ネットワークトラフィックメタデータを含む、請求項１に記載のシステム。
【請求項9】
前記プロセッサは、少なくとも部分的に、前記デバイスプロファイルを複数の他のデバイスプロファイルと比較することに基づいて、前記推奨セキュリティポリシを生成する、ように構成されている、請求項１に記載のシステム。
【請求項10】
前記複数の他のデバイスプロファイルは、デバイスタイプを共有している複数の他のデバイスに対応する、請求項９に記載のシステム。
【請求項11】
前記IoTデバイスは、第１ネットワーク環境に配置されており、かつ、前記IoTデバイスと前記デバイスタイプを共有している少なくとも１つの他のデバイスは、前記第１ネットワーク環境とは異なる第２ネットワーク環境に配置されている、
請求項１０に記載のシステム。
【請求項12】
前記デバイスプロファイルを複数の他のデバイスプロファイルと比較することは、前記デバイスタイプを共有している複数の他のデバイスのうちの少なくともいくつかからの、前記IoTデバイスの挙動の逸脱を決定すること、を含む、
請求項１０に記載のシステム。
【請求項13】
前記デバイスタイプは、前記IoTデバイスの特定のモデルを指定する、請求項１に記載のシステム。
【請求項14】
前記デバイスタイプは、前記IoTデバイスの特定のベンダーを指定する、請求項１に記載のシステム。
【請求項15】
前記デバイスタイプは、前記デバイスによって提供される機能を指定する、請求項１に記載のシステム。
【請求項16】
方法であって、モノのインターネット(IoT)デバイスのネットワーク通信に関連付けられた情報を受信するステップと、
前記IoTデバイスに関連付けるために、デバイスタイプを含む、デバイスプロファイルを決定するように、前記受信した情報を使用するステップと、
前記デバイスプロファイルに少なくとも部分的に基づいて、セキュリティ機器によって前記IoTデバイスに適用されるべき推奨セキュリティポリシを生成するステップと、
を含む、方法。
【請求項17】
有形のコンピュータ可読記憶媒体に保管されたコンピュータプログラムであって、コンピュータ命令を含み、前記命令が実行されると、コンピュータに、
モノのインターネット(IoT)デバイスのネットワーク通信に関連付けられた情報を受信し、
前記IoTデバイスに関連付けるために、デバイスタイプを含む、デバイスプロファイルを決定するように、前記受信した情報を使用し、かつ、
前記デバイスプロファイルに少なくとも部分的に基づいて、セキュリティ機器によって前記IoTデバイスに適用されるべき推奨セキュリティポリシを生成する、
ようにさせる、コンピュータプログラム。
【発明の詳細な説明】
【背景技術】
【0001】
悪意のある個人は、様々な方法でコンピュータシステムを危険にさらす（compromise）ように試みる。一つの例として、そうした個人は、悪意のあるソフトウェア(「マルウェア（“malware”）」)を電子メール添付ファイルに埋め込み、または、他の形で含み、そして、疑うことを知らないユーザに対して送信し得る。実行されると、マルウェアは犠牲者のコンピュータを危険にさらし、そして、追加の不正なタスク(例えば、機密データの抽出、他のシステムへの伝播、等)を実行することができる。様々なアプローチを使用して、そうした危険および他の危険にさらされることに対してコンピュータを強化することができる。残念ながら、コンピュータを保護する既存のアプローチは、必ずしも全てのコンピューティング環境に適しているとは限らない。さらに、マルウェアの作者は、検出を回避するように彼らの技術を継続的に適合させている。そして、様々な状況において、マルウェアを検出し、かつ、その害を防止するための改善された技法に対する継続的な必要性が存在している。
【0002】
他の出願の相互参照
本出願は、2020年6月1日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である、米国仮特許出願第63/033,004号について優先権を主張する、2021年12月23日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である、米国特許出願第17/133,189号、現在では米国特許第11,115,799号の継続出願（continuation）である、2020年7月20日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である米国特許出願第17/381,103号の一部継続出願（continuation in part）である。これらの各々は、全ての目的のために、参照により本明細書に組み込まれている。
本出願は、2020年6月1日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である、米国仮特許出願第63/033,004号について優先権を主張する、2021年12月23日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である、米国特許出願第17/133,189号、現在では米国特許第11,115,799号の継続出願（continuation）である、2020年7月20日に出願された、タイトルが「IOT DEVICE DISCOVERY AND IDENTIFICATION」である米国特許出願第17/381,103号の一部継続出願（continuation in part）である。これらの各々は、全ての目的のために、参照により本明細書に組み込まれている。
【図面の簡単な説明】
【0003】
本発明の様々な実施形態が、以下の詳細な説明および添付の図面において開示されている。
【発明を実施するための形態】
【0004】
本発明は、プロセス、装置、システム、組成物、コンピュータ可読記憶媒体上に具現化されたコンピュータプログラム製品、及び／又は、メモリ上に記憶された命令、及び／又は、プロセッサに結合されたメモリにより保管さら、かつ／あるいは、提供される命令を実行するように構成されたプロセッサといった、プロセッサを含む、多数の方法で実施することができる。本明細書において、これらの実装形態、または、本発明がとり得る任意の他の形態は、技法（technique）と称され得る。一般的に、開示されたプロセスのステップの順序は、本発明の範囲内で変更され得る。特に明記しない限り、タスクを実行するように構成されているものとして説明されるプロセッサまたはメモリといったコンポーネントは、所与の時間にタスクを実行するように一時的に構成される汎用コンポーネント、または、タスクを実行するように製造される特定のコンポーネントとして実装され得る。本明細書で使用されるように、「プロセッサ（“processor”）」という用語は、コンピュータプログラム命令といった、データを処理するように構成された１つ以上のデバイス、回路、及び／又は、処理コアを指す。
【0005】
本発明の１つ以上の実施形態の詳細な説明が、本発明の原理を示す添付の図面とともに、以下で提供されている。本発明は、そうした実施形態に関連して説明されるが、本発明は、いかなる実施形態にも限定されるものではない。本発明の範囲は、請求項によってのみ限定されるものであり、かつ、本発明は、多数の代替、修正、および均等物を包含する。本発明の完全な理解を提供するために、以下の説明において多数の具体的な詳細が記載されている。これらの詳細は、例示の目的で提供されるものであり、そして、本発明は、これらの具体的な詳細の一部または全部を伴わずに、特許請求の範囲に従って実施され得る。明確にするために、本発明に関連する技術分野で知られている技術的材料は、本発明が不必要に不明瞭にならないように、詳細には説明されていない。
【0006】
I.概要
【0007】
ファイアウォールは、一般的に、承認された通信がファイアウォールを通過するのを許可し、一方で、不正アクセスからネットワークを保護している。ファイアウォールは、典型的には、ネットワークアクセスのためにファイアウォール機能を提供する、デバイス、一式のデバイス、または、デバイスにおいて実行されるソフトウェアである。例えば、ファイアウォールは、デバイス(例えば、コンピュータ、スマートフォン、または、他のタイプのネットワーク通信可能なデバイス)のオペレーティングシステムの中に統合することができる。ファイアウォールは、また、コンピュータサーバ、ゲートウェイ、ネットワーク／ルーティング（routing）デバイス(例えば、ネットワークルータ)、または、データアプライアンス(例えば、セキュリティ機器、または他のタイプの特殊目的デバイス)といった、様々なタイプのデバイスまたはセキュリティデバイス上のソフトウェアアプリケーションとして統合され、または実行することができ、そして、いくつかの実装では、特定の動作は、ASICまたはFPGAといった、特定目的ハードウェアで実装することができる。
る。
る。
【0008】
ファイアウォールは、典型的に、一式のルールに基づいてネットワーク送信を拒否または許可する。これらのルールのセットは、しばしば、ポリシ(例えば、ネットワークポリシ、またはネットワークセキュリティポリシ)として参照される。例えば、ファイアウォールは、不要な外部トラフィックが保護デバイスに到達するのを防ぐために、一式のルールまたはポリシを適用することによって、インバウンドトラフィック（inbound traffic）をフィルタリングすることができる。ファイアウォールは、また、一式のルールまたはポリシを適用することによってアウトバウンドトラフィックをフィルタリングすることができる(例えば、許可（allow）、ブロック（block）、モニタリング（monitor）、通知（notify）、またはログ（log）、及び／又は、ファイアウォールルールまたはファイアウォールポリシにおいて指定され得る他のアクションであり、これらは、ここにおいて説明されるような、様々な基準に基づいてトリガすることができる)。ファイアウォールは、また、同様に一式のルールまたはポリシを適用することによって、ローカルネットワーク(例えば、イントラネット)トラフィックをフィルタリングすることもできる。
【0009】
セキュリティデバイス(例えば、セキュリティ機器、セキュリティゲートウェイ、セキュリティサービス、及び／又は、他のセキュリティデバイス)は、様々なセキュリティ動作(例えば、ファイアウォール、アンチ－マルウェア、侵入防止／検出、プロキシ、及び／又は、他のセキュリティ機能)、ネットワーク機能(例えば、ルーティング、クオリティ・オブ・サービス（QoS)、ネットワーク関連リソースのワークロードバランシング、及び／又は、他のネットワーク機能)、及び／又は、他のセキュリティ及び／又はネットワーク関連の機能を実行することができる。例えば、ルーティングは、送信元（source）情報(例えば、IPアドレスおよびポート)、宛先（destination）情報(例えば、IPアドレスおよびポート)、および、プロトコル情報に基づいて実行することができる。
【0010】
基本的なパケットフィルタリング・ファイアウォールは、ネットワークを介して送信される個々のパケットを検査することによって、ネットワーク通信トラフィックをフィルタリングする(例えば、ステートレス（stateless）パケットフィルタリング・ファイアウォールである、パケットフィルタリング・ファイアウォールまたは第１世代ファイアウォール)。ステートレスパケットフィルタリング・ファイアウォールは、典型的に、個々のパケット自体を検査し、そして、検査されたパケットに基づいて(例えば、パケットの送信元および宛先のアドレス情報、プロトコル情報、および、ポート番号の組み合わせを使用して)ルールを適用する。
【0011】
アプリケーション・ファイアウォールは、また、(例えば、アプリケーション層フィルタリング・ファイアウォール、または、TCP/IPスタックのアプリケーションレベルにおいて機能する第２世代ファイアウォールを使用して)アプリケーション層フィルタリングを実行することもできる。アプリケーション層フィルタリング・ファイアウォールまたはアプリケーション・ファイアウォールは、一般的に、所定のアプリケーションおよびプロトコル(例えば、ハイパーテキスト転送プロトコル(HTTP)を使用したウェブブラウジング、ドメインネームシステム(DNS)要求、ファイル転送プロトコル(FTP)を使用したファイル転送、および、Telnet、DHCP、TCP、UDP、およびTFTP(GSS)といった、様々な他のタイプのアプリケーションおよび他のプロトコル)を識別することができる。例えば、アプリケーション・ファイアウォールは、標準ポートにおいて通信を試みる未認可（unauthorized）プロトコルをブロックすることができる(例えば、そのプロトコルについて非標準（non-standard）ポートを使用することにより黙って通り抜けること（sneak through）を試みる未認可／外れたポリシプロトコルは、一般的に、アプリケーション・ファイアウォールを使用して識別することができる)。
【0012】
ステートフル・ファイアウォールは、また、ステートフル・ベースのパケット検査を実行することもでき、そこでは、各パケットが、そのネットワーク送信のパケットフロー（packets/packet flow）と関連する一式のパケットのコンテキストの中で検査される。このファイアウォール技術は、一般的に、ステートフル・パケット検査として参照される。ファイアウォールを通過する全ての接続の記録を保持し、そして、パケットが、新しい接続の開始であるか、既存の接続の一部であるか、または、無効なパケットであるかを判断することができるからである。例えば、接続の状態は、それ自体が、ポリシの中のルールをトリガするクライテリアの１つになり得る。
【0013】
先進的または次世代ファイアウォールは、上述のように、ステートレスおよびステートフルなパケットフィルタリングおよびアプリケーション層フィルタリングを実行することができる。次世代ファイアウォールは、また、追加のファイアウォール技術を実行することもできる。例えば、先進的または次世代ファイアウォールとして、しばしば参照される所定の新しいファイアウォールは、また、ユーザおよびコンテンツを識別することができる。特に、所定の次世代ファイアウォールは、これらのファイアウォールが自動的に識別できるアプリケーションのリストを、何千ものアプリケーションまで拡大している。そうした次世代ファイアウォールの例は、Palo Alto Networksから市販されている(例えば、Palo Alto NetworksのPAシリーズのファイアウォール)。例えば、Palo Alto Networksの次世代ファイアウォールは、様々な識別技術を使用して、企業およびサービスプロバイダが、アプリケーション、ユーザ、およびコンテンツ－単にポート、IPアドレス、およびパケットだけでなく－を識別し、かつ、制御することを可能にする。様々な識別技術は、正確なアプリケーション識別のためのアプリケーションID（App-ID)、ユーザ識別のためのユーザID（User-ID)（例えば、User ID)、リアルタイムなコンテンツスキャニングのためのコンテンツID（Content-ID)（例えば、Webサーフィンを制御し、かつ、データおよびファイルの転送を制限する)、および、デバイスID（Device-ID）（例えば、IoTデバイスタイプの識別のため）といったものである。これらの識別技術により、企業は、従来のポートブロッキングファイアウォールによって提供される従来のアプローチに従う代わりに、ビジネス関連の概念を使用して、アプリケーションの使用を安全に可能にすることができる。また、（例えば、専用装置として実装される）次世代ファイアウォールのための特定目的ハードウェアは、汎用ハードウェアにおいて実行されるソフトウェアよりも、アプリケーション検査についてより高いパフォーマンスレベルを一般的に提供する(例えば、Palo Alto Networks社が提供するセキュリティ機器といったものであり、シングルパス・ソフトウェアエンジンと堅く統合されている、専用の、機能固有の処理を利用し、Palo Alto NetworksのPAシリーズ次世代ファイアウォールについて、レイテンシ（latency）を最小化する一方で、ネットワークのスループットを最大化する)。
【0014】
先進的または次世代ファイアウォールは、また、仮想化ファイアウォールを使用して実装することもできる。そうした次世代ファイアウォールの例は、Palo Alto Networks社から市販されている(Palo Alto Networksのファイアウォールは、VMware(R) ESXiTMおよびNSXTM、Citrix(R)Netscaler SDXTM、KVM/OpenStack(Centos/RHEL、Ubuntu(R))、および、Amazon Web Services(AWS)を含む、様々な商用仮想化環境をサポートしている)。例えば、仮想化ファイアウォールは、物理的フォームファクタ機器で利用可能な、同様の、または、完全に同一の次世代ファイアウォールおよび先進的な脅威防止機能をサポートすることができ、企業は、プライベート、パブリック、およびハイブリッドなクラウドコンピューティング環境へのアプリケーションの流入を安全に可能にすることができる。VMモニタリング、ダイナミックアドレスグループ、およびRESTベースのAPIといった自動化機能により、企業は、VMの変化を動的にモニタすることができ、そのコンテキストをセキュリティポリシに反映させて、それにより、VMの変化時に生じ得るポリシの遅れ（lag）を排除している。
【0015】
II.例示的な環境
【0016】
図1は、悪意のあるアクティビティが検出され、そして、その害が低減される環境の例を示している。図1に示される例において、クライアントデバイス104－108は、病院(「アクメ病院（“Acme Hospital”）」とも呼ばれる)の企業ネットワーク110において(それぞれに)存在するラップトップコンピュータ、デスクトップコンピュータ、および、タブレットである。データアプライアンス102は、クライアントデバイス104および106といった、クライアントデバイスと、企業ネットワーク110の外部の(例えば、外部ネットワーク118を介して到達可能な)ノードとの間の通信に関するポリシを実施するように構成されている。
【0017】
そうしたポリシの例は、トラフィックの成形、クオリティ・オブ・サービス（quality of service）、および、トラフィックのルーティングを管理するものを含んでいる。ポリシの他の例は、着信（incoming）(及び／又は送信（outgoing）)電子メールの添付ファイル、ウェブサイトコンテンツ、インスタントメッセージングプログラムを介して交換されるファイル、及び／又は、他のファイル転送における脅威についてスキャンを必要とするものといった、セキュリティポリシを含んでいる。いくつかの実施形態において、データアプライアンス102は、また、企業ネットワーク110内に留まるトラフィックに関してポリシを実施するように構成されている。
【0018】
ネットワーク110は、また、ディレクトリサービス154、および、認証、認可、および課金(Authetication,Authorization,and Accounting、AAA)サーバ156を含んでいる。図1に示される例では、ディレクトリサービス154(アイデンティティプロバイダまたはドメインコントローラとも呼ばれる)は、ライトウェイトディレクトリアクセスプロトコル(Lightweight Directory Access Protocol、LDAP)、または、他の適切なプロトコルを利用する。ディレクトリサービス154は、ユーザ識別および証明書情報を管理するように構成されている。ディレクトリサービス154の一例は、Microsoft社のActive Directoryサーバである。アクティブディレクトリサーバの代わりに、ケルベロスベース（Kerberos-based）のシステムといった、他のタイプのシステムも、また、使用することができ、本明細書で説明される技術は、それに応じて適合される。図1に示される例において、AAAサーバ156は、ネットワークアドミッション制御(network admission server、NAC)サーバである。AAAサーバ156は、ネットワークに対する有線、無線、およびVPNのユーザおよびデバイスを認証し、ネットワークへのアクセスを許可する前に、ポリシコンプライアンスについてデバイスを評価して、修正し、かつ、役割に基づいてアクセスを区別し、そして、次いで、誰がネットワーク上にいるかについて監査および報告するように構成されている。AAAサーバ156の一例は、リモート認証ダイヤルインユーザサービス(Remote Authentication Dial-In User Service、RADIUS)を利用するシスコ社のアイデンティティサービスエンジン(ISE)サーバである。RADIUS以外のプロトコルを使用するものを含み、他のタイプのAAAサーバが、本明細書で説明される技法とともに使用され得る。
【0019】
様々な実施形態において、データアプライアンス102は、ディレクトリサービス154及び／又はAAAサーバ156への／からの（to/from）通信をリッスンする(例えば、メッセージを受動的にモニタリングする)ように構成されている。様々な実施形態において、データアプライアンス102は、ディレクトリサービス154及び／又はAAAサーバ156と通信する(すなわち、能動的にメッセージを通信する)ように構成されている。様々な実施形態において、データアプライアンス102は、ディレクトリサービス154及び／又はAAAサーバ156といった、様々なネットワーク要素と通信する(例えば、メッセージを能動的に通信する)オーケストレータ(図示なし)と通信するように構成されている。他のタイプのサーバも、また、ネットワーク110に含まれてよく、かつ、適用可能な場合にデータアプライアンス102と通信することができ、そして、ディレクトリサービス154及び／又はAAAサーバ156も、また、様々な実施形態においてネットワーク110から省略され得る。
【0020】
図1では、単一のデータアプライアンス102を有するように示されているが、所与のネットワーク環境(例えば、ネットワーク110)は、個別に動作するか、または協調して動作するかにかかわらず、データアプライアンスに係る複数の実施形態を含むことができる。同様に、「ネットワーク（“network”）」という用語は、本明細書では、簡単にするために、一般的に、単数形で(例えば、「ネットワーク110」として)呼ばれるが、本明細書で説明する技法は、適用可能な場合に、様々なネットワークレイヤにわたり様々なネットワーキングプロトコル(例えば、TCPおよびUDP)、および、インフラストラクチャ(例えば、スイッチおよびルータ)を使用して、ネットワーキング技術(例えば、仮想および物理)の様々な混合を含む、様々なサイズおよびトポロジの様々なネットワーク環境において展開され得る。
【0021】
データアプライアンス102は、リモートセキュリティプラットフォーム140と協働して動作するように構成され得る。セキュリティプラットフォーム140は、(例えば、サンプル分析モジュール124を介して)マルウェアサンプルについて静的および動的分析を実行すること、および、既知の悪意のあるファイル、ドメイン、等の署名（signature）のリストを、サブスクリプションの一部としてデータアプライアンス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のオペレータによって所有され、かつ、そのオペレータの制御下にある専用ハードウェアによって提供される。
【0022】
データアプライアンスの一つの実施形態が図2Aに示されている。示される例は、種々の実施形態において、データアプライアンス102に含まれる物理的コンポーネントの表現である。具体的に、データアプライアンス102は、高性能マルチコア中央処理ユニット（CPU）202およびランダムアクセスメモリ（RAM）204を含んでいる。データアプライアンス102は、また、ストレージ210(１つ以上のハードディスクまたはソリッドステートユニット、といったもの）を含む。様々な実施形態において、データアプライアンス102は、企業ネットワーク110をモニタリングすること、および、開示された技術を実装することに使用される情報を(RAM204、ストレージ210、及び／又は、他の適切なロケーション、のいずれかに)保管する。そうした情報の例は、アプリケーション識別子、コンテンツ識別子、ユーザ識別子、要求されたURL、IPアドレスマッピング、ポリシおよび他の構成情報、署名、ホスト名／URL分類情報、マルウェアプロファイル、機械学習モデル、IoTデバイス分類情報、等を含む。データアプライアンス102は、また、１つ以上の任意的なハードウェアアクセラレータを含み得る。例えば、データアプライアンス102は、暗号化および復号動作を実行するように構成された暗号エンジン206、および、照合器（matching）を実行し、ネットワークプロセッサとして動作し、かつ／あるいは、他のタスクを実行するように構成された、１つ以上のフィールドプログラマブルゲートアレイ208を含み得る。
【0023】
データアプライアンス102によって実行されるものとしてここにおいて説明される機能性は、種々の方法で提供／実装することができる。例えば、データアプライアンス102は、専用のデバイスまたはデバイスセットであってよい。所与のネットワーク環境は、複数のデータアプライアンスを含んでよく、その各々は、ネットワークの特定の部分にサービスを提供するように構成されてよく、ネットワークの特定の部分にサービスを提供するように協働し得る、など。データアプライアンス102によって提供される機能は、汎用コンピュータ、コンピュータサーバ、ゲートウェイ、及び／又は、ネットワーク／ルーティング・デバイス上のソフトウェアとして統合され、または、実行され得る。いくつかの実施形態において、データアプライアンス102によって提供されるものとして説明される少なくともいくつかの機能性（functionality）が、代わりに(または、これに加えて)、クライアントデバイスにおいて実行しているソフトウェアによって、クライアントデバイス(例えば、クライアントデバイス104またはクライアントデバイス106)に提供される。データアプライアンス102によって実行されるものとして本明細書で説明される機能性は、また、セキュリティプラットフォーム140によって、または、それと協働して、少なくとも部分的に実行することもでき、かつ／あるいは、セキュリティプラットフォーム140によって実行されるものとして本明細書で説明される機能性は、適用可能な場合、データアプライアンス102によって、または、それと協働して少なくとも部分的に実行することもできる。一つの例として、IoTモジュール138によって実行されるものとして説明される様々な機能は、IoTサーバ134の実施形態によって実行され得る。
【0024】
データアプライアンス102がタスクを実行するものとして記述されるときはいつでも、単一のコンポーネント、コンポーネントのサブセット、またはデータアプライアンス102の全てのコンポーネントは、タスクを実行するために協働することができる。同様に、データアプライアンス102のコンポーネントがタスクを実行するものとして説明されるときはいつでも、サブコンポーネントは、タスクを実行することができ、かつ／あるいは、コンポーネントは、他のコンポーネントと共にタスクを実行することができる。様々な実施形態において、データアプライアンス102の一部は、１つ以上の第三者によって提供される。データアプライアンス102に利用可能な計算リソースの量といった要因に応じて、データアプライアンス102の種々の論理コンポーネント及び／又は特徴は省略されてよく、そして、ここにおいて説明される技術はそれに応じて適合される。同様に、追加の論理コンポーネント／特徴を、データアプライアンス102の実施形態に、適用可能なように含めることができる。種々の実施形態におけるデータアプライアンス102に含まれるコンポーネントの一つの例は、(例えば、パケットフロー解析に基づいてアプリケーションを識別するために種々のアプリケーション署名を使用して)アプリケーションを識別するように構成されているアプリケーション識別エンジンである。例えば、アプリケーション識別エンジンは、セッションが関与するトラフィックのタイプを決定することができる。Webブラウジング－ソーシャルネットワーキング、Webブラウジング－ニュース、SSH、等といったものである。様々な実施形態においてデータアプライアンス102に含まれるコンポーネントの別の例は、IoTサーバ134であり、より詳細に以下で説明される。IoTサーバ134は、物理的であるか仮想化されているかにかかわらず、スタンドアロンサーバ(または、サーバのセット)としてのものを含み、様々な形態をとることができ、そして、また、適用可能な場合、(例えば、図1に示されるように)データアプライアンス102とコロケートされ／それに組み込まれてもよい。
【0025】
図2Bは、データアプライアンスの一つの実施形態の論理コンポーネントの機能図である。示される例は、種々の実施形態においてデータアプライアンス102に含まれ得る論理コンポーネントの表現である。別段の規定がない限り、データアプライアンス102の種々の論理コンポーネントは、一般的に、１つ以上のスクリプト(例えば、該当する場合、Java、python、等で書かれたもの)のセット（set）を含む種々の方法で実装可能である。
【0026】
図示のように、データアプライアンス102はファイアウォールを備え、かつ、管理プレーン212およびデータプレーン214を含んでいる。管理プレーンは、ポリシの設定およびログデータの表示のめのユーザインターフェイスを提供するといったことにより、ユーザインタラクション（user interaction）の管理について責任を負う。データプレーンは、パケット処理およびセッション処理を実行するといったことにより、データ管理について責任を負う。
【0027】
ネットワークプロセッサ216は、クライアントデバイス108といった、クライアントデバイスからパケットを受信し、そして、それらを処理のためにデータプレーン214に提供するように構成されている。フローモジュール218は、新しいセッションの一部としてパケットを識別するときはいつでも、新しいセッションフローを生成する。その後のパケットは、フロールックアップに基づいて、セッションに属しているものとして識別される。該当する場合、SSL復号エンジン220によってSSL復号化が適用される。そうでなければ、SSL復号エンジン220による処理は省略される。復号エンジン220は、データアプライアンス102がSSL/TLSおよびSSHの暗号化トラフィックを検査および制御することを助け、そして、従って、そうでなければ暗号化トラフィック内に隠されたままであり得る脅威を停止することを助ける。復号エンジン240は、また、機密性の高いコンテンツが企業ネットワーク110から去るのを防止することを助けることができる。復号は、URLカテゴリ、トラフィック元、トラフィック宛先、ユーザ、ユーザグループ、およびポート、といったパラメータに基づいて選択的に制御することができる(例えば、イネーブルされ、または、ディセーブルされる)。復号ポリシ(例えば、復号するセッションを指定するもの)に加えて、復号プロファイルは、ポリシによって制御されるセッションの様々なオプションを制御するために割り当てることができる。例えば、特定の暗号スイートおよび暗号化プロトコルバージョンの使用が要求され得る。
【0028】
アプリケーション識別(APP-ID)エンジン222は、セッションが関与するトラフィックのタイプを決定するように構成されている。一つの例として、アプリケーション識別エンジン222は、受信データ内のGETリクエストを認識し、そして、セッションがHTTPデコーダを必要とすると結論付けることができる。場合によって、例えば、ウェブブラウジングセッションにおいて、識別されたアプリケーションは変更することができ、そして、そうした変更はデータアプライアンス102によって書き留め（noted）られる。例えば、ユーザは、まず、企業のWiki(訪問したURLに基づいて「Webブラウジング－生産性（“Web Browsing-Productivity”）」として分類される)を閲覧し、次に、ソーシャルネットワーキングサイト(訪問したURLに基づいて「Webブラウジング－ソーシャルネットワーキング（“Web Browsing-Social Networking”）」として分類される)を閲覧することができる。異なるタイプのプロトコルは、対応するデコーダを有している。
【0029】
アプリケーション識別エンジン222によって行われた決定に基づいて、パケットが、脅威エンジン224によって、パケット（順序が乱れて受信され得る）を正しい順序に組み立て、そして、情報を抽出するように構成されている、適切なデコーダに対して、送信される。脅威エンジン224は、また、パケットに何が起こるべきかを決定するために、署名照合（signature matching）を実行する。必要に応じて、SSL暗号化エンジン226は、復号されたデータを再び暗号化することができる。パケットは、転送のために(例えば、宛先へ)転送モジュール228を使用して転送される。
【0030】
また、図２Bにも示されるように、ポリシ232も、受信され、そして、管理プレーン212に保管される。ポリシは、ドメイン名、及び／又は、ホスト／サーバ名を使用して指定することができる、１つ以上のルールを含むことができ、そして、ルールは、モニタリングされるセッショントラフィックフローからの様々な抽出されたパラメータ／情報に基づいて、加入者／IPフローに対するセキュリティポリシ実施のためといった、１つ以上の署名または他の照合基準または発見的方法を適用することができる。インターフェイス（I／F）通信器230が、管理通信(例えば、(REST)API、メッセージ、またはネットワークプロトコル通信、もしくは他の通信メカニズムを介して)について提供されている。ポリシ232は、また、IoTデバイスを含む通信を管理するためのポリシも含むことができる。
【0031】
III.IoTデバイスの発見および識別
【0032】
図1に戻って、悪意のある個人が(例えば、システム120を使用して)、マルウェア130を作成したと仮定する。悪意のある個人は、脆弱なクライアントデバイスがマルウェア130のコピーを実行することを望み、クライアントデバイスを危険にさらし、そして、クライアントデバイスをボットネット内のボットにさせている。危険にさらされたクライアントデバイスは、次いで、タスク(例えば、暗号通貨マイニング、サービス妨害攻撃への参加、および、他の脆弱なクライアントデバイスへの伝播)を実行するように、そして、外部エンティティ(例えば、コマンドアンドコントロール(C&C)サーバ150)に対して情報を報告するか、または、そうでなければ、データを抽出するように、並びに、適用可能な場合には、C&Cサーバ150から命令を受信するように、命令され得る。
【0033】
図1に示されるいくつかのクライアントデバイスは、典型的に企業組織内で使用される、コモディティコンピューティングデバイスである。例えば、クライアントデバイス104、106、および108は、典型的なオペレーティングシステム(例えば、macOS（登録商標）、Windows(登録商標)、Linux(登録商標)、Android、等)を、それぞれ実行する。そうしたコモディティコンピューティングデバイスは、しばしば、(例えば、それぞれに、企業発行のラップトップ、デスクトップ、およびタブレットとして)管理者によってプロビジョニングおよび維持され、そして、しばしば、(例えば、ユーザ識別および証明書情報を用いて構成されたディレクトリサービスプロバイダ(ドメインコントローラとも呼ばれる)によって管理される)ユーザアカウントとともに動作される。一つの例として、従業員アリス（Alice）にラップトップ104が支給され、彼女のACME関連電子メールにアクセスし、そして、様々なACME関連タスクを実行するために使用される。他のタイプのクライアントデバイス(本明細書では、一般的に、モノのインターネットまたはIoTデバイスと呼ばれる)も、また、ますますネットワーク内に存在しており、そして、しばしばIT部門によって「管理されていない（“unmanaged”）」。いくつかのそうしたデバイス(例えば、電話会議デバイス)は、様々な異なるタイプの企業にわたり(例えば、IoTホワイトボード144および146として)見出され得る。そうしたデバイスは、また、垂直型（vertical specific）であってもよい。例えば、注入ポンプ（infusion pumps）およびコンピュータ断層撮影スキャナ(例えば、CTスキャナ112)は、ヘルスケア企業ネットワーク(例えば、ネットワーク110)内で見出され得る、IoTデバイスの例であり、そして、ロボットアームは、製造企業ネットワーク内で見出され得るデバイスの例である。さらに、消費者向けIoTデバイス(例えば、カメラ)も、また、企業ネットワーク内に存在し得る。コモディティコンピューティングデバイスと同様に、ネットワーク内に存在するIoTデバイスは、そうしたネットワークの内部または外部の両方(または、適用可能な場合には両方)にあるリソースと通信し得る。
【0034】
コモディティコンピューティングデバイスと同様に、IoTデバイスは、悪質な個人のターゲットである。残念ながら、ネットワーク内のIoTデバイスの存在は、いくつかのユニークなセキュリティ／管理上の課題を提示するし得る。IoTデバイスは、しばしば、低電力デバイスまたは専用デバイスであり、そして、ネットワーク管理者の知識なしに、しばしば、配備される。そうした管理者に知られている場合でさえ、IoTデバイス上にエンドポイント保護ソフトウェアまたはエージェントをインストールすることが可能でないことがある。
IoTデバイスは、独自の(または、そうでなければ非標準の)プロトコルを使用して、第三者クラウドインフラストラクチャ(例えば、クラウドインフラストラクチャ126と直接的に通信する工業温度計152を伴う)によって管理され、かつ、単独で／直接的に通信することができる。これは、デバイスに対していつ脅威または攻撃が起こっているかに関して決定を下すために、そうしたデバイスの内外のネットワークトラフィックをモニタリングする試みを混乱させ得る。さらに、(例えば、ヘルスケア環境における)いくつかのIoTデバイスは、ミッションクリティカルである(例えば、ネットワーク接続された手術システム)。残念ながら、(例えば、マルウェア130によって)IoTデバイスが危険にさらされること、または、IoTデバイスに関連付けられたトラフィックに対するセキュリティポリシの誤適用は、潜在的に壊滅的な影響を有し得る。本明細書で説明される技術を使用して、IoTデバイスを含む異種ネットワークのセキュリティを改善することができ、かつ、そうしたネットワークにもたらされる危害を低減することができる。
IoTデバイスは、独自の(または、そうでなければ非標準の)プロトコルを使用して、第三者クラウドインフラストラクチャ(例えば、クラウドインフラストラクチャ126と直接的に通信する工業温度計152を伴う)によって管理され、かつ、単独で／直接的に通信することができる。これは、デバイスに対していつ脅威または攻撃が起こっているかに関して決定を下すために、そうしたデバイスの内外のネットワークトラフィックをモニタリングする試みを混乱させ得る。さらに、(例えば、ヘルスケア環境における)いくつかのIoTデバイスは、ミッションクリティカルである(例えば、ネットワーク接続された手術システム)。残念ながら、(例えば、マルウェア130によって)IoTデバイスが危険にさらされること、または、IoTデバイスに関連付けられたトラフィックに対するセキュリティポリシの誤適用は、潜在的に壊滅的な影響を有し得る。本明細書で説明される技術を使用して、IoTデバイスを含む異種ネットワークのセキュリティを改善することができ、かつ、そうしたネットワークにもたらされる危害を低減することができる。
【0035】
様々な実施形態において、データアプライアンス102は、IoTサーバ134を含んでいる。IoTサーバ134は、いくつかの実施形態において、セキュリティプラットフォーム140のIoTモジュール138と協働して、ネットワーク(例えば、ネットワーク110)内のIoTデバイスを識別するように構成されている。そうした識別は、IoTデバイスに関連付けられたトラフィックに関するポリシを作成して、実施するのを助けるために、そして、ネットワーク110の他の要素の機能を強化するために(例えば、コンテキスト情報をAAA156に提供する)、例えば、データアプライアンス102によって、使用され得る。様々な実施形態において、IoTサーバ134は、トラフィックを受動的にスニフ（sniff）し／モニタリングするように構成された１つ以上のネットワークセンサを組み込んでいる。そうしたネットワークセンサ機能を提供する１つの例示的な方法は、タップインターフェイスまたはスイッチミラーポートとしてのものである。トラフィックをモニタリングする他のアプローチも、また、適用可能な場合に、(追加または代替として)使用され得る。
【0036】
様々な実施形態において、IoTサーバ134は、(例えば、受動的にモニタリングネットワーク110から収集された)ログまたは他のデータを(例えば、フロントエンド142を介して)IoTモジュール138に提供するように構成されている。図2Cは、IoTサーバとIoTモジュールとの間の一つの例示的なイベント経路（path）を示している。IoTサーバ134は、デバイス発見イベントおよびセッションイベントをIoTモジュール138に送信する。例示的な発見イベントおよびセッションイベントが、それぞれに、図2Dおよび図2Eに示されている。様々な実施形態において、発見イベントは、デバイスの識別情報（identity）を一意に識別または確認することができるパケットを観測するときはいつでも(例えば、DHCP、UPNP、またはSMBパケットが観測されるときはいつでも)、IoTサーバ110によって送信される。デバイスが有する(デバイスのネットワークの内部または外部いずれかの、他のノードとの)各セッションは、セッションに関する情報(例えば、送信元／宛先（source/destination）情報、受信／送信されたパケットの数、等)を要約するセッションイベント内に記述される。適用可能な場合、複数のセッションイベントが、IoTモジュール138に送信する前に、IoTサーバ134によって一緒にバッチ処理され得る。図2Eに示される例では、２つのセッションが含まれている。IoTモジュール138は、デバイス評決イベントを介して、IoTサーバ134にデバイス分類情報を提供する(234)。
【0037】
IoTモジュール138を実装する一つの例示的な方法は、マイクロサービスベースのアーキテクチャを使用することである。IoTモジュール138は、また、適用可能な場合に、異なるプログラミング言語、データベース、ハードウェア、およびソフトウェア環境を使用して、かつ／あるいは、メッセージング対応（messaging enabled）であり、コンテキストによって境界を定められ、自律的に開発され、独立して展開可能であり、分散され、そして、自動化プロセスを用いて構築およびリリースされるサービスとしても実装され得る。IoTモジュール138によって実行される１つのタスクは、IoTサーバ134によって提供される(かつ、データアプライアンス136および148といったデータアプライアンスの他の実施形態によって提供される)データにおいてIoTデバイスを識別し、そして、それらのデバイスに関する追加のコンテキスト情報を提供する(例えば、それぞれのデータアプライアンスに戻す)ことである。
【0038】
図2Fは、IoTモジュールの一つの実施形態を示している。領域295は、全てのテナントのデータにわたり間隔を置いて(例えば、5分ごと、1時間ごと、および、毎日)実行されるスパークアプリケーション（Spark Application）のセットを示している。領域297は、カフカ（Kafka）メッセージバスを示している。IoTモジュール138によって(例えば、IoTサーバ134から)受信したセッションイベントメッセージは、(例えば、帯域幅を節約するために)IoTサーバ134において観測される際に複数のイベントを一緒にバンドルする。変換モジュール236は、受信したセッションイベントを個々のイベントへと平坦化し、そして、250においてそれらを発行するように構成されている。平坦化されたイベントは、様々な異なる集約ルールを使用して、集約モジュール238によって集約される。一つの例示的なルールは、「時間間隔（例えば、5分）について、特定のデバイス、および、それが使用する各アプリケーション（APP-ID）について、全てのイベントデータを集約する」である。別の例示的なルールは、「時間間隔(例えば、1時間)について、特定の宛先IPアドレスと通信する特定のデバイスについて、全てのイベントデータを集約する」である。各ルールについて、集約エンジン238は、集約される必要がある属性のリスト(例えば、デバイスによって使用されるアプリケーションのリスト、または、宛先IPアドレスのリスト)を追跡する。特徴抽出モジュール240は、属性から特徴(252)を抽出する。分析モジュール242は、抽出された特徴を使用して、(例えば、教師あり及び教師なし学習を使用して)デバイス分類を実行し、その結果(254)は、(例えば、動作インテリジェンスモジュール244、脅威分析モジュール246、および、異常検出モジュール248を介して)他のタイプの分析に電力供給（power）するために使用される。動作インテリジェンスモジュール244は、OTフレームワーク、および、動作（operational）またはビジネスインテリジェンスに関連する解析(例えば、デバイスがどのように使用されているか)を提供する。アラート(256)は、分析の結果に基づいて生成され得る。様々な実施形態において、モンゴDB（MongoDB）258は、集約されたデータおよび特徴値を格納するために使用される。バックグラウンドサービス262は、スパークアプリケーションによって集約されたデータを受信し、そして、データをモンゴDB 258に書き込む。APIサーバ260は、フロントエンド142から受信した要求に応えるために、モンゴDB 258からデータを引き出して、マージする。
【0039】
図2Gは、(例えば、分析モジュール242および関連要素に係る一実施形態としてのIoTモジュール138の中で)IoTデバイス識別分析を実装する一つの例示的な方法を示している。発見イベントおよびセッションイベント(例えば、図2Dおよび図2Eで、それぞれに、示されるようなもの)は、メッセージバス上でカフカトピックとして、メッセージバス上の生データ264として受信される(そして、また、ストレージ158にも保管される)。特徴は、特徴エンジン276によって抽出される(例えば、スパーク／マップリデューサ（MapReducer）を使用して実装され得る)。生データは、セキュリティプラットフォーム140によって、(例えば、送信元／宛先アドレスの)地理位置情報といった、追加のコンテキスト情報を用いて強化される(266)。メタデータ特徴抽出(268)の最中には、IPアドレスからある時間間隔内に送信されたパケットの数、その時間間隔中に特定のデバイスによって使用されたアプリケーションの数、および、その時間間隔中にデバイスによって連絡されたIPアドレスの数といった特徴が、構築される。特徴は、(例えば、メッセージバス上で)インライン分析エンジン272に(例えば、JSONフォーマットで)リアルタイムに渡され、かつ、(例えば、オフラインモデリング299中の)後続のクエリのために(例えば、アパッチパーケット（Apache Parquet）／データフレーム（Data Frame）といった適切なフォーマットで、特徴データベース270に)保管される、の両方である。
【0040】
メタデータから構築される特徴に加えて、本明細書では分析特徴と呼ばれる、第２タイプの特徴が、IoTモジュール138によって構築され得る(274)。一つの例示的な分析特徴は、集約データを使用して、時系列データに基づいて経時的に構築されるものである。解析特徴は、同様に、分析エンジン272にリアルタイムに渡され、かつ、特徴データベース270に保管される。
【0041】
インライン分析エンジン272は、メッセージハンドラを介して、メッセージバス上で特徴を受信する。実行される１つのタスクは、アクティビティ分類(278)であり、受信した特徴値／セッション情報に基づいてセッションに関連するアクティビティ(ファイルダウンロード、ログイン／認証プロセス、または、ディスクバックアップアクティビティといったもの)を識別しようと試み、そして、任意の適用可能なタグを添付する。アクティビティ分類278を実装する１つの方法は、畳み込みネットワークと組み合わされたニューラルネットワークベースの多層（multi-layer）パーセプトロンを介するものである。
【0042】
アクティビティ分類の結果として、特定のデバイスが、印刷アクティビティに従事しており(すなわち、印刷プロトコルを使用している)、そして、また、(例えば、HP URLを呼び出し、かつ、ステータス情報を報告するためにそれを使用することによって、更新をチェックするために)HPによって所有されているリソースに定期的にコンタクトしている、ことが判断されたと仮定する。様々な実施形態において、分類情報は、クラスタリングプロセス(教師なし)、および、予測プロセス(教師あり)の両方に渡される。いずれかのプロセスがデバイスの分類に成功した場合、その分類はデバイスデータベース286に保管される。
【0043】
デバイスは、その属性および他の挙動パターンに基づいて、ステージ１（stage one）クラスタリングエンジン280によって、複数のクラスタ(例えば、プリンタのように動作する、HPデバイスのように動作する、等)へとクラスタリングされ得る。クラスタリングエンジン280を実装する１つの方法は、極端勾配ブースティングフレームワーク（extreme gradient boosting framework）(例えば、XGB)を使用することである。ステージ１の分類器は、以前には見られなかったが、既存の既知のデバイスに類似しているデバイスを分類するのに有用であり得る(例えば、サーモスタットの新しいベンダーが、既知のサーモスタットと同様に挙動するサーモスタットデバイスを販売し始めている)。
【0044】
図2Gに示されるように、アクティビティ分類情報は、また、分類器282のセットにも提供され、そして、デバイスについて提供された特徴に基づいて、予測が実行される。２つの可能性が生じ得る。第１シナリオでは、デバイスが既知のデバイスプロファイルに一致する高い確率(すなわち、高い信頼性スコア)が存在していると決定される。そうであれば、デバイスに関する情報がステージ２（stage two）分類器(284)に提供され、それは、(例えば、提供された情報、および、任意の追加の適用可能なコンテキスト情報を使用して)デバイスの識別について最終的な判定（verdict）を行い、そして、それに応じて、デバイスデータベース286を更新する。ステージ２の分類器を実装する１つの方法は、勾配ブースティングフレームワークを使用することである。第２シナリオでは、信頼度スコアが低いと仮定する(例えば、デバイスは、HPプリンタとHPラップトップの両方に50%の信頼度で一致している)。このシナリオにおいて、分類器282によって決定された情報は、クラスタリングにおいて使用可能な追加の情報としてクラスタリングエンジン280に提供され得る。
【0045】
図2Gには、オフラインモデリングモジュール299も、また、示されている。オフラインモデリングモジュール299は、時間制約されていないので、インライン分析エンジン272とは対照的である(一方で、インライン分析エンジン272は、デバイス分類情報を(例えば、メッセージ234として)リアルタイムに提供しようと試みる)。定期的に(例えば、１日に１回、または、１週間に１回)、オフラインモデリングモジュール299（例えば、パイソン（Python）を使用して実装されるもの)は、インライン分析モジュール272によって使用されるモデルを再構築する。アクティビティモデリングエンジン288は、アクティビティ分類278のためにモデルを構築し、それは、また、インライン分析中にデバイス識別のために分類器によって使用される、デバイスタイプモデル(296)についても、また、使用される。ベースラインモデリングエンジン290は、デバイスモデルのベースライン挙動のモデルを構築し、それは、また、キルチェーン（kill chain）といった、特定のタイプのデバイス異常(292)、および、特定のタイプの脅威(294)をモデル化するときにも使用される。生成されたモデルは、様々な実施形態において、モデルデータベース298に保管される。
【0046】
IV.ネットワークエンティティID AAA
【0047】
前述のように、アリスには、ACMEによってラップトップ104が発行されたと仮定する。ネットワーク110の様々な構成要素は、アリスが様々なリソースにアクセスするために使用する際に、アリスのラップトップを認証するように協働する。一つの例として、アリスがラップトップ104をネットワーク110内に配置された無線アクセスポイント(図示なし)に接続するとき、無線アクセスポイントは、ネットワークアクセスをプロビジョニングしながら、AAAサーバ156と(直接的または間接的のいずれかで)通信することができる。別の例として、アリスが、彼女のACME電子メールにアクセスするためにラップトップ104を使用するとき、ラップトップ104は、彼女のインボックス、等フェッチしながら、ディレクトリサービス154と(直接的または間接的のいずれかで)通信することができる。コモディティオペレーティングシステムを実行するコモディティラップトップとして、ラップトップ104は、ラップトップ104が必要とする適切なリソースへのアクセスを得るのを助ける適切なAAAメッセージ(例えば、RADIUSクライアントメッセージ)を生成することができる。
【0048】
前述のように、110といったネットワーク内のIoTデバイス(例えば、デバイス146)によって提起される１つの問題は、そうしたデバイスが、しばしば、「管理されず（“unmanaged”）」(例えば、ネットワーク管理者によって、構成、プロビジョニング、管理されていない、等)、RADIUSといったプロトコルをサポートせず、そして、従って、ラップトップ104などの他のデバイスといったAAAサービスと統合され得ないことである。IoTデバイスにネットワーク110内のネットワークアクセスを提供するために、様々なアプローチが採用され得るが、それらの各々は欠点を有している。１つのオプションは、ACMEについて、IoTデバイスを(例えば、事前共有鍵（pre-shared key）を介して)ゲストネットワークの使用に制限することである。残念ながら、これは、IoTデバイスが、正当にアクセスを有するべきネットワーク110内の他のノードと通信することができない場合に、IoTデバイスの有用性を制限し得る。別のオプションは、IoTデバイスにネットワーク110に対する無制限なアクセスを許可することであり、セグメント化されたネットワークを有することのセキュリティ上の利益を軽減する。さらに別のオプションは、ACMEについて、所与のIoTデバイスがネットワーク110内のリソースにどのようにアクセスすることができるべきかを管理するルールを手動で指定することである。このアプローチは、一般的に、様々な理由で受け入れ難く／実行不可能である。一つの例として、管理者は、しばしば、IoTデバイスの配備に関与しなくてよく、そして、従って、そうしたデバイスに対するポリシが(例えば、データアプライアンス102において)含まれるべきであることを知らない。管理者が、例えば、アプライアンス102内の特定のIoTデバイスのための(例えば、デバイス112といったデバイスのための)ポリシを手動で構成し得る場合でさえも、そうしたポリシを最新に保つことは、エラーを起こしやすく、かつ、一般的に、ネットワーク110内に存在し得るIoTデバイスの膨大な数を考慮すると、受け入れ難い。さらに、そうしたポリシは、おそらく、単純であり(例えば、CTスキャナ112を、IPアドレス及び／又はMACアドレスによって、特定のネットワークに割り当てる)、そして、CTスキャナ112を含む接続／ポリシに対するよりきめの細かい制御(例えば、手術デバイス対POS（point of sales）端末に対して適用可能なポリシを動的に含む)を許可しない。さらに、CTスキャナ112がデータアプライアンス102に手動で含まれる場合でさえも、前述のように、IoTデバイスは、一般的に、RADIUSといった技術をサポートせず、そして、そうしたAAAサーバにCTスキャナ112のネットワーキングアクセスを管理させることの利点は、そうした技術をより完全にサポートする他のタイプのデバイス(例えば、ラップトップ104)と比較して、制限されるだろう。より詳細に以下で説明されるように、様々な実施形態において、データアプライアンス102は(例えば、IoTサーバ134を介して)、受動的な方法で、ネットワーク110内に存在するIoTデバイスに対して、AAA機能のサポートを提供するように構成されている。
【0049】
以下の説明では、ACMEにおけるアリスの部門が、最近、対話型ホワイトボード144を購入し、その結果、アリスが、他のACME従業員、並びに、ACMEの外部の個人(例えば、ボブ、ベータ大学（Beta University）の研究者であり、それ自体のネットワーク114、データアプライアンス136、および、ホワイトボード146を有している)と共同作業することができる、と仮定する。ホワイトボード146の初期セットアップの一部として、アリスは、ホワイトボードを電源に接続し、そして、(例えば、会議室のコンセントへの)有線接続、または、無線認証情報(例えば、会議室のビジターによる使用のための認証情報)をホワイトボードに提供する。ホワイトボード146がネットワーク接続をプロビジョニングするとき、IoTサーバ134は(例えば、上述のようなネットワークセンサといったメカニズムを介して)、ネットワーク110内の新しいデバイスとして、ホワイトボード146を認識する。この検出に応答して取られる１つのアクションは、セキュリティプラットフォーム140と通信することである(例えば、データベース160内にホワイトボード146について新しいレコードを作成し、そして、ホワイトボード146に関連付けられた任意の現在利用可能なコンテキスト情報を取り出す(例えば、ホワイトボード146の製造業者、ホワイトボード146のモデル、等を取得する))。セキュリティプラットフォーム140によって提供される任意のコンテキスト情報は、データアプライアンス102に提供(および、保管)され得る。それは、今度は、適用可能な場合、ディレクトリサービス154及び／又はAAAサーバ156に提供することができる。適用可能な場合、IoTモジュール138は、ホワイトボード146に関する更新されたコンテキスト情報を、それが利用可能になると、データアプライアンス102に提供することができる。そして、データアプライアンス102は(例えば、IoTサーバ134を介して)、同様に、ホワイトボード146に関する進行中の情報を、セキュリティプラットフォーム140に提供することができる。そうした情報の例は、ネットワーク110上のホワイトボード146の挙動に関する観察(例えば、それが行う接続に関する統計情報)を含み、ホワイトボード146といったデバイスについて挙動プロファイルを構築するために、セキュリティプラットフォーム140によって使用され得る。同様な挙動プロファイルが、他のデバイス(例えば、ホワイトボード144)について、セキュリティプラットフォーム140によって、構築され得る。そうしたプロファイルは、異常な挙動を検出することを含む、様々な目的のために使用することができる。一つの例として、データアプライアンス148は、セキュリティプラットフォーム140によって提供される情報を使用して、温度計152の履歴観測と比較して、かつ／あるいは、類似のモデル、製造業者の他の温度計(図示なし)と比較して、または、より一般的には、他のネットワーク内に存在する温度計を含めて、温度計152が異常に動作しているか否かを検出することができる。異常な挙動が(例えば、データアプライアンス148によって)検出された場合、適切な是正措置が自動的に講じられ得る。ネットワーク116上の他のノードに対する温度計152のアクセスを制限すること、アラートを生成すること、等といったものである。
【0050】
図3は、ネットワーク内のIoTデバイスについてAAAサポートを受動的に提供するためのプロセスに係る一つの実施形態を示している。様々な実施形態において、プロセス300は、IoTサーバ134によって実行される。プロセスは、IoTデバイスによって送信されたパケットのセットが取得されるときに、302において開始する。一つの例として、ネットワーク110上でホワイトボード146が最初にプロビジョニングされるとき、そうしたパケットは、302においてIoTサーバ134によって受動的に受信され得る。パケットは、また、ホワイトボード144に係る後続の使用の最中に、302において受信することもできる(例えば、アリスが、ホワイトボード146を介して、ボブとのホワイトボードセッションを有する際に)。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の代わりに、(例えば、302で受信された情報を使用して、そして、また、適用可能な場合、セキュリティプラットフォーム140からも)図4Aに示されるような、メッセージを生成することができる。前述のように、IoTサーバ134がホワイトボード146に関する情報をIoTモジュール138に提供するとき、IoTモジュール138は、種々のアクションをとることができる。データベース160内にホワイトボード146について記録を作成すること、および、その記録にホワイトボード146に関するコンテキスト情報を投入（populating）すること(例えば、その製造業者、モデル番号、等を決定する)といったものである。ホワイトボード146に関する追加のコンテキスト情報がセキュリティプラットフォーム140によって収集されると、そのプロファイルは更新され、そして、データアプライアンス102に伝搬され得る。ホワイトボード146がネットワーク110内で最初にプロビジョニングされるとき、追加のコンテキスト情報が利用可能でないことがある(例えば、セキュリティプラットフォーム140が、そうした追加の情報を有していないか、または、そうした情報をセキュリティプラットフォーム140によってIoTサーバ134に提供することが瞬時（instant）でないことがある)。従って、かつ、図4Aに示されるように、ホワイトボード146の代わりにIoTサーバ134によって生成されるRADIUSメッセージは、限られた情報を含み得る。追加のコンテキスト情報が(例えば、IoTサーバ134によって、IoTモジュール138から)受信されると、ホワイトボード146の代わりにIoTサーバ134によって送られる後続のRADIUSメッセージは、そうした追加の情報で強化され得る。そうした後続のメッセージの例が、図4Bおよび図4Cに示されている。図4Bは、ホワイトボード146に関するコンテキスト情報(例えば、多種多様なIoTデバイスに関するコンテキスト情報のデータベースを含むもの)が、一旦、IoTモジュール138によって提供されると、ホワイトボード146の代わりに、IoTサーバ134が送信することができる、RADIUSメッセージの一つの例を示している。図4Bに示される例では、ホワイトボードの製造業者(パナソニック)、および、デバイスの性質(例えば、それがインタラクティブホワイトボードであること)といったコンテキスト情報が含まれている。そうしたコンテキスト情報は、AAAサーバ156といったAAAサーバによって使用されて、(ホワイトボード146を修正する必要なしに)ホワイトボード146に対して、AAAサービスを提供することができる。電話会議機器専用のサブネットワーク上で、自動的にプロビジョニングすることによる、といったものである。他のタイプのIoTデバイスも、また、デバイスタイプ、目的、等といった属性に基づいて自動的にグループ化され得る(例えば、重要な外科手術用機器が、そうした機器専用のサブネットワーク上で自動的にプロビジョニングされ、そして、従って、ネットワーク上の他のデバイスから分離されている)。そうしたコンテキスト情報は、ソーシャルネットワーキングパケットよりもホワイトボード146パケットに優先的な扱いを与えるポリシ(例えば、APP-IDを使用して決定される)といった、トラフィックシェーピングポリシなどのポリシを実施するために使用され得る。きめの細かいポリシは、同様に、重要な外科手術用機器との通信に適用され得る(例えば、そうした機器と通信する任意のデバイスが、期限切れのオペレーティングシステムを有することを防止すること、等)。図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内の他のノードから隔離すること(または、そうでなければ、それらのアクセスを制限すること)、一方で、現在のオペレーティングシステムを有するIoTデバイスに対して、より制限の少ないネットワークアクセスを許可すること、等によって、コンテキスト情報に基づいてセキュリティポリシを実装することができる。
【0051】
図4A－図4Cは、RADIUSアクセス要求メッセージの例を示している。適用可能な場合、IoTサーバ134は、ホワイトボード146の代わりに、様々なタイプのRADIUSメッセージを生成することができる。一つの例として、ホワイトボード146からのトラフィックが最初に観測されたときに、RADIUSアカウンティング開始メッセージが、トリガされ得る。定期的なRADIUSアカウンティング暫定更新メッセージは、ホワイトボードが使用されている間に送信することができ、RADIUSアカウンティング停止メッセージは、ホワイトボード146がオフラインになったときに送信することができる。
【0052】
V.IoTデバイスの発見および識別
【0053】
上述のように、セキュリティプラットフォーム140によって(例えば、IoTモジュール138を介して)実行される１つのタスクは、IoTデバイス分類である。一つの例として、IoTサーバ134が、デバイス発見メッセージをIoTモジュール138に送信すると、IoTモジュール138は、デバイスについて分類を決定し、そして、(例えば、図2Cに示される判定234により)応答するように試みる。デバイスは、適用可能な場合、デバイスの後続の分類が実行される必要がない(または、適用可能な場合、そうでない場合に実行されるよりも低い頻度で実行される)ように、IoTモジュール138によって一意の識別子に関連付けられる。また、上述のように、決定された分類は、デバイスへの／からのトラフィックに対してポリシを実施するために(例えば、データアプライアンス102によって)使用され得る。
【0054】
デバイスを分類するために、様々なアプローチが使用され得る。第１アプローチは、組織的に一意の識別子(organizationally unique identifier、OUI)、それが実行するアプリケーションのタイプ、等といった、デバイスの静的属性を活用する、ルール／ヒューリスティクス（heuristics）のセットに基づいて、分類を行うことである。第２アプローチは、そのネットワークトラフィックから抽出されるデバイスの動的であるが、事前定義された属性(例えば、1日当たりに送信されるパケットの数)を活用する、機械学習技法を使用して、分類を行うことである。残念ながら、これらのアプローチは両方とも弱点を有している。
【0055】
ルールベースのアプローチは、一般的に、IoTデバイスの各タイプについて別個のルールが手動で作成されることを必要とする(デバイスの署名のタイプについて、どの属性／値が署名として使用されるべきかを記述している)。このアプローチによって提示される１つの課題は、どの署名が、共に、デバイスを識別することに関連し、かつ、他のデバイス署名の中で一意であるか、を決定することにある。さらに、ルールベースのアプローチでは、トラフィックから容易に取得することができる限られた数の静的属性が利用可能である(例えば、ユーザエージェント、OUI、URL宛先、等)。属性は、一般的に、正規表現（regular expression）が一致することができるパターンで現れるのに十分に単純である必要がある。別の課題は、新しいデバイスが市場に参入する(例えば、CTスキャナの新しいブランドまたはモデルが提供される)際に、存在し／識別可能であり得る、新しい静的属性を識別することにある。別の課題は、ルールがトリガされるためには、ネットワークトラフィック内の全ての一致する属性が収集される必要があることである。より少ない属性では、判定に達することができない。一つの例として、署名は、特定のOUIを有する特定のデバイスが、特定のURLに接続することを要求し得る。OUI自体を有することは、既にデバイスの識別の十分なインジケータであり得るが、署名は、URLも、また、観察されるまでトリガしない。このことは、デバイスの識別を決定することにおいて、さらなる遅延を引き起こす。別の課題は、経時的に変化するデバイスの静的属性として、署名を維持および更新することである(例えば、デバイスまたはデバイスによって使用されるサービスに対して行われる更新のため)。一つの例として、特定のデバイスは、最初に第１タイプのネットワークカードを使用して製造されたが、時間の経過により、製造業者は、(異なるOUIを示す)異なるネットワークカードに切り替えた可能性がある。ルールベースシステムが変更に気付いていない場合、偽陽性（false positive）が結果として生じ得る。さらに別の課題は、毎日オンラインにされる新しいIoTデバイスの数が、数百万の新たなデバイスインスタンスに近づくときの、署名の生成／検証のスケーリングにある。その結果として、新たに作成されたルールは、既存のルールと競合し得るものであり、そして、分類において偽陽性を引き起こす。
【0056】
機械学習ベースのアプローチは、一般的に、ネットワークトラフィックから抽出された静的特徴及び／又は動的特徴に基づいて、トレーニングモデルを作成することを含んでいる。新しいIoTデバイスからのネットワークデータに対する予測の結果は、関連する精度を有するデバイスの識別情報を提供する事前にトレーニングされたモデルに基づいている。機械学習的アプローチの問題の例は、以下のようである。予測が、新しいデバイスごとに、または、一定／一意のID(例えば、MACアドレス)を有していないデバイスに対して行われる場合、所望の精度に達するために必要とされる計算時間は許容できないことがある。生成される必要がある数千または数万の特徴が存在し、かつ、それらの特徴が、既定の時間ウィンドウ（time window）にわたり変換することがあり、有効な予測を行うために十分な数の特徴が利用可能になる前に、かなりの時間を要している(それは、ポリシ実施の目的を無効にし得る)。さらに、予測における遅延を最小限にすることが目的である場合には、ネットワークデータをストリーミングするための大規模なデータパイプラインを構築し、かつ、維持するためのコストが高くなり得る。さらに別の問題は、所与の展開環境に特有の無関係な特徴によってもたらされるノイズが、予測の精度を低下させ得ることである。そして、デバイスタイプの数が数万以上に達するときは、モデルを維持すること、および、更新することに課題が存在している。
【0057】
様々な実施形態において、セキュリティプラットフォーム140は、分類に対してハイブリッドアプローチを使用することによって、２つの前述のアプローチのそれぞれの問題に対処する。例示的なハイブリッドアプローチでは、ネットワーク挙動パターン識別子(本明細書では、また、パターンIDとも呼ばれる)が、デバイスの各タイプについて生成される。様々な実施形態において、パターンIDは、(特徴または挙動カテゴリについて重要性スコアとして)それぞれの確率と組み合わせられた、属性またはシーケンス特徴のリストであり、それは、別個のネットワーク挙動記述を形成し、そして、IoTデバイスのタイプを識別するために使用され得る。パターンIDは、(例えば、データベースに)保管され、そして、デバイスの識別を識別／検証するために使用され得る。
【0058】
属性のセットについてトレーニングするときに、極端勾配ブースティングフレームワーク(例えば、XGB)といった、所定のアプローチは、(静的属性、動的属性、及び／又は、アグリゲートされ／変換された値であるか、にかかわらず)重要な特徴のトップリストを提供することができる。パターンIDは、一旦確立されたデバイスタイプを一意に識別するために使用され得る。特定の特徴がデバイスについて支配的である場合(例えば、特定の静的特徴(ブート時に非常に特定的なURLに連絡する、といったこと)が、98%の信頼度でデバイスを識別する)、それらは、ルールを自動的に生成するために、使用され得る。支配的な特徴が存在しない場合であってさえ、上位の特徴の表現は、それでもなお、パターンIDとして使用され得る(例えば、複数の特徴のセットがパターンに連結されている場合)。全ての既知のモデル(および、全ての既知のIoTデバイス)を含むデータセットについてトレーニングすることによって、モデル／一意に識別する特徴の間の潜在的な競合が回避され得る。さらに、パターンIDは、人間が読み取り可能である必要はない(しかし、識別目的のために、保管、共有、及び／又は、再使用され得る)。このアプローチによって、著しい時間節約も、また、実現され得る。その結果、ほぼリアルタイムの分類に使用され得る。支配的な特徴が観察されるとすぐに(多数の特徴が発生するまで待つことを要する代わりに)、特定のデバイスの分類が発生し得る。
【0059】
“Teem Room Display iPad（登録商標）”デバイスについてパターンIDを作成するために使用され得るデータの一つの例は、以下を含み得る(多変量モデルのトレーニングまたは複数のバイナリモデルのトレーニングを通して自動的に生成された完全なリストを伴う)。
*Appleデバイス(100%)
*特別なiPad(>98.5%)
*ティームルームアプリ(>95%)
*ボリュームパターンVPM-17を満たす(>95%)
*クラウド内サーバ(>80%)
*Appleデバイス(100%)
*特別なiPad(>98.5%)
*ティームルームアプリ(>95%)
*ボリュームパターンVPM-17を満たす(>95%)
*クラウド内サーバ(>80%)
【0060】
ハイブリッドアプローチを実施する一つの例示的な方法は、以下のとおりである。ニューラルネットワークベースの機械学習システムが、自動化されたパターンIDトレーニングおよび生成のために使用され得る。ニューラルネットワークモデルをトレーニングするために使用され得る特徴の例は、ネットワークトラフィックから抽出された静的特徴(例えば、OUI、ホスト名、TLS指紋、一致したL7ペイロード署名、等)、および、ネットワークトラフィックから抽出されたが環境に固有ではないシーケンス特徴(例えば、アプリケーション、アプリケーションのL7属性、カテゴリ特徴に変換されたボリューム範囲、等)の両方を含んでいる。特徴生成のために選択されたネットワークデータをリアルタイムでストリーミングするために、軽量（lightweight）データパイプラインが使用され得る。予測エンジンは、モデルをインポートし、そして、予測の遅延を最小化するようにキャッシングを提供するために、使用され得る。予測においては、短い(例えば、分ベースの)集約が、選択された配列特徴を安定化するために、使用され得る。カスタマイズされたデータ正規化、強化、集約、および、変換技術が、配列特徴を操作するために、使用され得る。より良好な精度のために、より長い集約ウィンドウが、トレーニングにおいて使用され得る。時間の経過にわたり、マージされ、そして、集約されている特徴を用いて、予測について精度が改善され得る。バックエンドフィードバックエンジンは、パターンID予測のために使用される属性を拡張するのに役立つ、「スローパス（“slow path”）」予測システム(例えば、デバイスタイプのモデリングサブシステム、および、デバイスグループのモデリングサブシステムを含む、機械学習ベースのアプローチ)の結果をルーティングするために使用され得る。デバイスグループモデルは、十分なサンプルまたは特徴が利用可能でないときに、デバイスタイプモデルに伴う問題を補償して、許容可能な閾値を超えて精度を改善するようにトレーニングされ得る(例えば、既定のタイプのセットに基づいて予測結果を割り当てること、そのうちのいくつかは、ラベル付けされていない同様のタイプのデバイスをクラスタ化するために別のサブシステムに付随する)。最終的に、リアルタイム予測エンジンからの結果を公開するために、判定モジュールが使用され得る。
【0061】
本明細書で説明されるような、分類に対するハイブリッドアプローチの例示的な利点は、以下のとおりである。第１に、高速収束（fast convergence）が発生し、所与のデバイスが、数分または数秒以内に潜在的に識別されることを可能にする。第２に、本発明は、ルールベースおよび機械学習ベースのシステムの個々の問題に対処する。第３に、それは、予測結果における安定性および一貫性を提供する。第４に、それは、数万(または、それ以上)の異なるタイプのIoTデバイスをサポートするスケーラビリティを有している。予測は、一般的に、新しいデバイスに対してのみ必要とされる(所与のデバイスが、L3ネットワークトラフィックベースの識別といった、一意のID割当てを欠いている場合でさえも)。
【0062】
モジュール138の実施形態が図5に示されている。IoTモジュール138を実装する一つの例示的な方法は、サービスが細粒度（fine-grained）であり、かつ、プロトコルが軽量である、マイクロサービスベースのアーキテクチャを使用することである。サービスは、また、適用可能な場合、異なるプログラミング言語、データベース、ハードウェア、および、ソフトウェア環境、及び／又は、メッセージング対応であり、コンテキストによって境界を定められ、自律的に開発され、独立して展開可能であり、分散され、そして、自動化されたプロセスを用いて構築およびリリースされる、比較的小さいサービス、を使用して実装され得る。
【0063】
前述のように、様々な実施形態において、セキュリティプラットフォーム140は、ネットワーク(例えば、ネットワーク110)上でIoTデバイスに関する情報を(例えば、データアプライアンス102から)定期的に受信する。いくつかのケースにおいて、IoTデバイスは、セキュリティプラットフォーム140(例えば、昨年ネットワーク110上にインストールされたCTスキャナ)によって以前に分類されている。他のケースにおいて、IoTデバイスは、セキュリティプラットフォーム140によって新たに見られる(例えば、ホワイトボード146が初めて設置されている)。所与のデバイスがセキュリティプラットフォーム140によって以前に分類されていないと仮定する(例えば、一意のデバイス識別子、および、関連付けられたデバイス情報のセットを保管するデータベース286内に、デバイスのエントリが存在しない)。図5に示すように、新しいデバイスに関する情報は、分類のために２つの異なる処理パイプラインに提供され得る。パイプライン504は、(パターンIDベースの方式に対応する)「高速パス（“fast path”）」の分類用パイプラインを表し、そして、パイプライン502は、(機械学習ベースの方式に対応する)「低速パス（“slow path”）」の分類用パイプラインを表している。
【0064】
パイプライン504においては、高速パス特徴エンジニアリングが実行され(508)、デバイスの適用可能な静的特徴およびシーケンス特徴を識別する。高速パス予測が、パターンIDまたは以前に構築されたモデルを使用して(例えば、上位の重要な特徴に基づいて、かつ、オフライン処理パイプライン506を使用して構築されたモデル)、実行される(510)。特定のパターンに一致しているデバイスの信頼性スコアが決定される(512)。デバイスに対する信頼性スコアが事前トレーニングされた閾値を満たす場合(例えば、0.9といった、モジュール138、または、その構成要素の全体的な予測精度に基づく)、分類は、適用可能な場合、(デバイスデータベース516内の)デバイスに割り当てられるか、または、更新され得る。最初に、信頼度スコアは、ほぼリアルタイムの高速パス処理に基づいている。このアプローチの利点は、データアプライアンス102が、デバイスのトラフィックにポリシを非常に迅速に適用し始めることができることである(例えば、モジュール138がデバイスを新規／未分類として識別してから数分以内)。アプライアンス102は、システム140からの分類判定を保留（pending）して、フェイルセーフ（fail-safe）(例えば、種々のネットワークリソースにアクセスするデバイスの能力を低減／制限する)、または、フェイルセーフ(例えば、デバイスの広範なアクセスを可能にする)するように構成され得る。追加の情報が利用可能になると(例えば、低速パス処理を介して)、適用可能な場合、信頼度スコアは、その追加情報に基づくことができる(例えば、信頼度スコアを増加させること、または、高速パス分類の最中になされた誤りを修正／訂正すること)。
【0065】
使用することができる特徴(例えば、静的属性および配列特徴)の例は、以下を含んでいる。パターンIDは、以下を含む、論理条件を伴う、これらの属性の任意の組み合わせであり得る。
*macアドレス内のOUI
*復号されたプロトコルからのホスト名文字列
*HTTP、および他のクリアテキストプロトコルからのユーザエージェント文字列
*復号されたSNMP応答からのシステム名文字列
*復号されたLDAPプロトコルからのOS、ホスト名、ドメイン、およびユーザ名
*復号されたDNSプロトコルからのURL
*SMBバージョン、コマンド、復号されたSMBプロトコルからのエラー
*TCPフラグ
*復号されたDHCPプロトコルからのオプション文字列
*医療におけるデジタル画像および通信(Digital Imaging and Communications in Medicine、DICOM)といった、復号されたIoTプロトコルからの文字列
*ローカルネットワークからのインバウンドアプリケーションのリスト
*インターネットからのインバウンドアプリケーションのリスト
*ローカルネットワークへのアウトバウンドアプリケーションのリスト
*インターネットへのアウトバウンドアプリケーションのリスト
*ローカルネットワークからのインバウンドサーバポートのリスト
*インターネットからのインバウンドサーバポートのリスト
*ローカルネットワークへのアウトバウンドサーバポートのリスト
*インターネットへのアウトバウンドサーバポートのリスト
*ローカルネットワークからのインバウンドIPのリスト
*インターネットからのインバウンドURLのリスト
*ローカルネットワークへのアウトバウンドIPのリスト
*インターネットへのアウトバウンドURLのリスト
*macアドレス内のOUI
*復号されたプロトコルからのホスト名文字列
*HTTP、および他のクリアテキストプロトコルからのユーザエージェント文字列
*復号されたSNMP応答からのシステム名文字列
*復号されたLDAPプロトコルからのOS、ホスト名、ドメイン、およびユーザ名
*復号されたDNSプロトコルからのURL
*SMBバージョン、コマンド、復号されたSMBプロトコルからのエラー
*TCPフラグ
*復号されたDHCPプロトコルからのオプション文字列
*医療におけるデジタル画像および通信(Digital Imaging and Communications in Medicine、DICOM)といった、復号されたIoTプロトコルからの文字列
*ローカルネットワークからのインバウンドアプリケーションのリスト
*インターネットからのインバウンドアプリケーションのリスト
*ローカルネットワークへのアウトバウンドアプリケーションのリスト
*インターネットへのアウトバウンドアプリケーションのリスト
*ローカルネットワークからのインバウンドサーバポートのリスト
*インターネットからのインバウンドサーバポートのリスト
*ローカルネットワークへのアウトバウンドサーバポートのリスト
*インターネットへのアウトバウンドサーバポートのリスト
*ローカルネットワークからのインバウンドIPのリスト
*インターネットからのインバウンドURLのリスト
*ローカルネットワークへのアウトバウンドIPのリスト
*インターネットへのアウトバウンドURLのリスト
【0066】
いくつかのケースにおいては、512で決定された信頼度スコアが非常に低いことがある。これが起こり得る１つの理由は、デバイスが新しいタイプであり(例えば、セキュリティプラットフォーム140によって以前に分析されていない新しいタイプのIoT玩具または他のタイプの製品)、そして、セキュリティプラットフォーム140上でデバイスについて利用可能な対応するパターンIDが存在しないためである。そうしたシナリオにおいて、デバイスに関する情報および分類結果は、例えば、デバイスによって示される挙動および他の適用可能な情報に対してクラスタリング(514)を実行することができる(例えば、デバイスが無線デバイスであること、プリンタのように作用すること、DICOMプロトコルを使用すること、等を判定するため)、オフライン処理パイプライン506に提供され得る。クラスタリング情報は、ラベルとして適用され、そして、適用可能な場合、追加の調査518のためにフラグ付けされて、その後に続いて見られる任意の類似のデバイスは自動的に一緒にグループ化される。調査の結果として、所与のデバイスに関する追加情報が決定される場合(例えば、新しいタイプの消費者向けIoT食肉温度計（meat thermometer）に対応するものとして識別される)、デバイス(および、同様の特性を有する全ての他のデバイス)は、それに応じて(例えば、ブランドXYZ食肉温度計として)再ラベル付けすることができ、関連付けられたパターンIDを生成され、そして、適用可能な場合(例えば、モデルが再構築された後に)、パイプライン502／504によって使用可能にすることができる。様々な実施形態において、オフラインモデリング520は、IoTデバイス識別のために使用される様々なモデル522をトレーニングし、かつ、更新するために毎日実行するプロセスである。様々な実施形態において、モデルは、新しいラベル付けされたデバイスをカバーするために毎日リフレッシュされ、そして、(低速パスパイプライン502について)挙動変化を反映し、かつ、その週の間に追加された新しい特徴およびデータインサイトに適応するために、毎週再構築される。新しいタイプのデバイスをセキュリティプラットフォーム140に追加するとき(すなわち、新しいデバイスパターンを作成する)、複数の既存のデバイスパターンが影響を受ける可能性があり、特徴のリストまたはそれらの重要性スコアのいずれかが更新されるのを必要とすることに留意すること。このプロセスは、自動的に実行され得る(そして、ルールベースのソリューションと比較して大きな利点である)。
【0067】
高速パスモデリングのために、ニューラルネットワークベースのモデル(例えば、FNN)、および、一般的な分類モデル(例えば、XGB)が、多変数機械学習モデルのために広範に使用されている。結果を改善し、クラスタリングへの入力を提供するのを助けるために、選択されたプロファイルについて、バイナリモデルも、また、構築される。バイナリモデルは、デバイスの識別情報、または、デバイスの所定の挙動に対して、はい／いいえ（yes/no）の回答を与える。例えば、デバイスがIP電話のタイプであるか、または、IP電話である可能性が低いかを判定するために、バイナリモデルが使用され得る。多変量モデルは、1の確率に対して正規化された多くの出力を有する。各出力は、デバイスのタイプに対応している。バイナリモデルは、一般的には、より高速であるが、正しい「はい（“yes”）」の答えを見つけることができるように、デバイスが、予測においてそれらの多くを通過することが必要となる。多変量モデルは、１つのステップで、それを達成することができる。
【0068】
低速パスパイプライン502は、特徴が抽出される(524)という点で、パイプライン504と同様である。しかしながら、パイプライン502によって使用される特徴は、典型的には、構築するために、ある期間を要する。一つの例として、「１日当たりに送信されるバイト数」という特徴は、収集するために１日を必要とする。別の例として、所定の使用パターンは、発生／観察されるのに、ある期間を要し得る(例えば、CTスキャナは、スキャンを実行するために毎時使用され(第１挙動)、データを毎日バックアップし(第２挙動)、そして、毎週更新について製造業者のウェブサイトを毎週チェックする(第３挙動))。低速パスパイプライン502は、特徴の完全なセットに対して新しいデバイスインスタンスを分類する試みにおいて、多変量分類器(526)を呼び出す。使用される特徴は、静的特徴またはシーケンス特徴に限定されるものではなく、同様に、ボリュームおよび時系列ベースの特徴も含む。これは、一般的に、ステージ１予測と呼ばれる。ステージ１予測の結果が最適でない場合(信頼度が低い)、特定のプロファイルについて、結果を改善するためにステージ２予測が使用される。低速パスパイプライン502は、新たなデバイスインスタンスを分類するために、追加のインポートされたデバイスコンテキストによってサポートされる決定木分類器のセット(528)を呼び出す。追加のデバイスコンテキストは、外部ソースからインポートされる。一つの例として、デバイスが接続したURLは、特徴として含まれ得るカテゴリおよびリスクベースの評判が与えられてきてよい。別の例として、デバイスによって使用されるアプリケーションは、特徴として含まれ得るカテゴリおよびリスクベースのスコアを与えられてきてよい。ステージ１予測526およびステージ２予測528からの結果を組み合わせることによって、低速パス分類の最終判定が、導出された信頼性スコアを用いて達成され得る。
【0069】
一般的には、低速パスパイプライン502に含まれる、２つのステージが存在している。低速パスパイプラインでは、いくつかの実施形態において、ニューラルネットワーク技法に基づいて、ステージ１モデルが、多変量分類器を用いて構築される。低速パスパイプラインのステージ２は、一般的に、ステージ１の確率関連の例外を処理するための追加の論理を伴う決定ベースモデルのセットである。予測において、ステージ２は、ステージ１からの入力を統合し、ルールおよびコンテキストを適用して、ステージ１の出力を検証し、そして、低速パスの最終出力を生成する。最終的な出力は、デバイスの識別情報、全体的な信頼度スコア、将来の高速パスパイプライン504に使用され得るパターンID、および、説明リストを含む。信頼性スコアは、モデルの信頼性および精度(モデルは、また、信頼性スコアも有している)、および、分類の一部としての確率に基づいている。説明リストは、結果に寄与する、特徴のリストを含む。上述のように、結果が既知のパターンIDから逸脱した場合に、調査がトリガされ得る。
【0070】
いくつかの実施形態においては、低速パスモデリングについて、２つのタイプのモデルが構築される。１つは、個人識別のためのものであり、そして、１つは、グループ識別のためのものである。例えば、異なるベンダーからの、または、異なるモデルを有する２つのプリンタ間の差異を見分けることは、しばしば、温度計からプリンタを区別することよりも困難である(例えば、プリンタは、ネットワーク挙動を示し、類似のプロトコルを話す、等の傾向があるため)。様々な実施形態においては、様々なベンダーからの様々なプリンタがグループの中に含まれ、そして、「プリンタ（“printer”）」モデルが、グループ分類のためにトレーニングされる。このグループ分類結果は、特定のプリンタの特定のモデルよりも良好な精度を提供することができ、そして、適用可能な場合、デバイスの信頼度スコアを更新するため、または、個々のプロファイルの識別情報ベースの分類に対して参照および検証を提供するために使用され得る。
【0071】
図6は、IoTデバイスを分類するためのプロセスに係る一つの例を示している。様々な実施形態において、プロセス600は、セキュリティプラットフォーム140によって実行される。プロセス600は、また、適用可能な他のシステム(例えば、IoTデバイスとオンプレミスで共配置（collocate）されたシステム)によって実行され得る。プロセス600は、IoTデバイスのネットワーク通信に関連付けられた情報が受信されたとき、602において開始する。一つの例として、そうした情報は、データアプライアンス102が、所与のIoTデバイスのデバイス発見イベントをセキュリティプラットフォーム140に送信するときに、セキュリティプラットフォーム220によって受信される。604では、デバイスが分類されていない(または、適用可能な場合、再分類が実行されるべきである)という決定が行われる。一つの例として、プラットフォーム140は、デバイスが分類されているか否かを判定するために、データベース286にクエリすることができる。606では、二部（two-part）分類が実行される。一つの例として、606において、高速パス情報の提供パイプライン504および低速パス分類パイプライン502の両方に対して、デバイスに関する情報を提供して、プラットフォーム140によって、二部分類が実行される。最終的に、608では、606で実行された分類プロセスの結果が、ベースラインモデリング（290）から集約されたネットワーク挙動と共に、IoTデバイスに対してポリシを適用するように構成されたセキュリティ機器に提供される。そうしたネットワーク挙動の例は、最も多く使用されたアプリケーション、URL、および、IoTデバイスプロファイルについて機械学習でトレーニングされたベースラインから「抽出（“extracted”）」され得る、セキュリティ機器ポリシの形成に役立つ、他の属性を含んでいる。上述のように、これは、高度にきめの細かいセキュリティポリシが、最小限の管理努力を用いて潜在的にミッションクリティカルな環境において実装されるのを可能にする。
【0072】
プロセス600を実行する第１例において、Xbox Oneゲームコンソールがネットワーク110に接続されていると仮定する。分類の最中には、デバイスが以下の主要な特徴を有するという決定がなされ得る。100%の信頼度を有する「ベンダーはマイクロソフトである（“vendor=Microsoft”）」特徴、89.7%の信頼度を有する「マイクロソフトクラウドサーバと通信する（“communicates with Microsoft cloud server”）」特徴、および、78.5%の信頼度を有する「ゲームコンソール（“game console”）」の一致特徴。これらの３つの特徴／信頼度スコアは、デバイスをXbox Oneゲームコンソールであると識別するために、プロファイルIDのセット(ニューラルネットワークベースの予測によって行われるプロセス)に対して集合的に照合され得る(すなわち、512において、閾値を満たすプロファイルID一致が見出される)。第２例においては、AudioCodes IP電話がネットワーク110に接続されていると仮定する。分類の最中に、デバイスが、100%の信頼度で「ベンダーはAudioCodesである（“vendor=AudioCodes”）」特徴に一致し、98.5%の信頼度で「IPオーディオデバイスである（“is IP audio device”）」特徴に一致し、かつ、66.5%で「ローカルサーバのように動作する（“act as local server”）」特徴に一致する、という判定を行うことができる。これらの３つの特徴／信頼度スコアは、また、プロファイルIDのセットに対しても照合されるが、このシナリオでは、十分な信頼度で一致する既存のプロファイルIDは無いものと仮定する。デバイスに関する情報は、次いで、クラスタリングプロセス514に提供され得る。そして、適用可能な場合、新しいプロファイルIDが最終的に生成され、かつ、デバイスに関連付けされ得る(そして、将来のデバイスを分類するために使用される)。
【0073】
適用可能な場合、セキュリティプラットフォーム140は、より詳細に以下で説明される、決定された分類に基づいて特定のポリシを推奨することができる。以下は、実施することができるポリシの例である。
*全ての注入ポンプについて(ベンダーに関係なく)インターネットトラフィックを拒否する。
*所定のGEホストから／へ（from/to）を除いて、全てのGE ECGマシンについてインターネットトラフィックを拒否する。
*全てのCTスキャナについて(ベンダーに関係なく)画像保存通信システム(Picture Archiving and Communication System、PACS)サーバへの内部トラフィックのみを許可する。
*全ての注入ポンプについて(ベンダーに関係なく)インターネットトラフィックを拒否する。
*所定のGEホストから／へ（from/to）を除いて、全てのGE ECGマシンについてインターネットトラフィックを拒否する。
*全てのCTスキャナについて(ベンダーに関係なく)画像保存通信システム(Picture Archiving and Communication System、PACS)サーバへの内部トラフィックのみを許可する。
【0074】
VI.ファイアウォールにおけるIoTセキュリティポリシ
【0075】
上述のように、IoTデバイスは、しばしば、ネットワーク上で観測され得る事前定義された挙動を有する(ラップトップといった汎用コンピューティングデバイスとは対照的な)専用デバイスである。一つの例として、製造業者(例えば、GEまたは富士通)に関係なく、CTスキャナは、他のCTスキャナと同様の機能を有し／同様の挙動をネットワーク上で示す。１つ以上の特定のプロトコルを使用して、キャプチャされた患者画像を、医療スタッフが検査するために(例えば、サーバへのインターフェイスを介して)ネットワーク化された画像サーバに送信する、といったものである。他のタイプのシステム(例えば、暖房、換気、および空調(HVAC)システム)は、それら自体の一連の類似の典型的な事前定義された挙動を示す(例えば、特定のプロトコルを介して、温度値をサーバに、１分１回報告する)。
【0076】
上述のように、(例えば、データアプライアンス102によって)観察されたトラフィックからの(例えば、セキュリティプラットフォーム140による)これらの挙動の分析により、特定のIoTデバイスを識別され得る(特定の、デバイスののインスタンス、デバイスのモデル、デバイスの製造業者、デバイスのタイプ、等を、識別することによるものを含む)。さらに、デバイス識別の副産物（bi-product）は、分類の目的で(例えば、ベースラインモデリングエンジン290によって)トレーニングされたデバイスベースラインモデルを有することになる。適用可能な場合、異常検出モジュール248は、デバイス(または、デバイスのグループ)についてベースラインを作成するときに、既知の異常な挙動をフィルタ除去するために使用され得る。このディープマシンラーニングモデルは、上述のネットワーク挙動をキャプチャする。このベースラインモデルは、デバイス識別予測において使用され得るだけでなく、ネットワーク挙動がデバイスプロファイル上でどれほど人気があって見られるかによってランク付けされた挙動の集約に係る共通リストを生成するためにも使用され得る。挙動の集約に対する１つのアプローチは、XGBといったMLアルゴリズムを使用して、トレーニングプロセスの最中にベースラインモデルから、(デバイス識別において使用される)上位の寄与特徴を抽出し、そして、ランク付けすることである。他のアプローチも、また、使用され、もしくは、組み合わされ得る(例えば、ヒューリスティックアプローチ（heuristic approach）)。上位の(信頼性／信用閾値（confidence threshold）に従った)寄与特徴は、本質的に、トレーニングで使用される数千の属性または特徴から、デバイスのタイプが示す最も一般的なネットワーク挙動が何であるかをハイライトし、そして、推奨（recommendation）で使用され得る(例えば、特定のURL、プロトコル、等をホワイトリスト化／ブラックリスト化する)。挙動の集約は、どのアプリケーションが使用されるか、所定のネットワークドメインに対してどの接続が行われるか、アプリケーションにおいてどのペイロードが搬送されるか、通信の量、時間、および頻度、等を含み得る。各属性には、「まれ（“rare”）」、「しばしば（“often”）」、または「規則的（“regular”）」といった頻度カテゴリ（frequency category）が割り当てられる。各属性には、また、「１時間当たり1MB未満（“less than 1MB per hour”）」といった範囲カテゴリを割り当てることもできる。異常(例えば、危険にさらされ、または、誤動作している／誤構成されたIoTデバイス)は、ベースラインからの逸脱として(例えば、異常検出モジュール248と連携して動作するデータアプライアンス102によって)検出され得る。これらの属性(および、特定の攻撃に対する既知の脆弱性)は、特定のIoTデバイス、デバイスのタイプ、等に関連付けられたネットワークアクティビティを制約するための推奨されるファイアウォールポリシを自動的に作成するための青写真（blueprint）として使用され得る。例えば、定期的に使用されるアプリケーションおよびURLは、「許可（“allow”）」ファイアウォールポリシを構築するために使用され得る。別の例においては、ベースライン挙動の一部ではないアプリケーションが、「拒否（“deny”）」ファイアウォールポリシを構築するために使用され得る。ユーザは、数十万の類似のデバイスから要約されたネットワーク挙動の頻度に基づいて、ポリシを調整することができる。そして、任意の既知の脆弱性(例えば、特定の攻撃に対する特定のデバイスの脆弱性)は、適用可能な場合、別々にモデル化され、かつ、推奨されるポリシの中へ組み込まれ得る。所与のデバイスタイプについて上位の特徴の例は、デバイスが、特定のURL(例えば、www.siemens.com/updates)において、アップデートを、１日に概ね１回チェックすることである。デバイスタイプを共有しているデバイスの閾値数が同様のベースライン挙動を示す場合に、特徴は、そのデバイスタイプに関連するデバイスプロファイルのための推奨ホワイトリスト項目として選択され得る。
【0077】
図7Aは、Acmeがネットワーク110内に配備し得るCTスキャナ／画像サーバに関するポリシのセットを実装する第１アプローチを示す。特に、Acmeが2つのタイプのCTスキャナ(GEおよび富士通製)を配備したと仮定する。ネットワーク110の管理者(以下、チャーリーと呼ぶ)は、(例えば、適用可能な場合にデータアプライアンス102及び／又はセキュリティプラットフォーム140によって提供される)インターフェイスと対話（interact）することができ、そして、ネットワーク110内の各CTスキャナおよび画像サーバについて、それらが通信することを許可されるプロトコル、ポート、およびIPアドレスを手動で指定することができる。残念ながら、このアプローチは、時間がかかり、かつ、エラーを起こしやすい。一つの例として、新しいCTスキャナが環境に追加されるとき、チャーリーは、図7Aに示されるルールに手動で追加する必要があり、そして、また、(例えば、新しいCTスキャナが既存のものを置換し、かつ／あるいは、ネットワーク情報が変化する場合に)ルールの一部を潜在的に変更／除去する必要もある。環境内のIoTデバイスの総数が少なく、かつ、IoTデバイスに静的IPアドレスが割り当てられている場合には、図7Aに示されるようなルールの手動保守が実現可能であり得る。実際には、しかしながら、所与の環境は、数百または数千(またはそれ以上)のIoTデバイスを有し、かつ／あるいは、DHCPを使用し得るものであり、そして、ルールの手動保守は、実行不可能である。
【0078】
代替的なアプローチは、明細書で説明される技法に従って、アプリケーション(例えば、医療画像情報を通信するために使用されるネットワークトラフィックに対応している特定のプロトコル／ポート／等を示す「DICOM-App」)、および、デバイスタイプ(例えば、GE-X線デバイス)を抽象化することである。図7Aに示された規則の抽象化が図7Bに示されている。注目すべきことに、チャーリーは、IoTポリシに関連するIPアドレス、ポート、またはプロトコルを提供する必要はなく、むしろ、抽象化されたアプリケーションタイプおよびデバイスタイプを使用することができる。図7Bに示されるようなポリシは、データアプライアンス102によって、ランタイム時に、コンパイルさら、かつ、使用され得る。コンパイルの最中に、抽象化された要素(例えば、GE-Xray-Device)は、データアプライアンス102に保管された情報(APP-ID情報、IP情報、及び／又は、デバイスタイプの辞書といったもの)に基づいて、(例えば、そのデバイス識別に一致する各IoTデバイスのIPアドレスで)置き換えられる。
【0079】
チャーリーは、(例えば、所望であれば、前述の抽象化を使用して)IoTデバイスルールを手動で書くことを選択することができるが、セキュリティプラットフォーム140によっても、また、ポリシ推奨が提供され得る。推奨は、様々な実施形態において、様々な特性を共有しているデバイスのセットに係る(デバイスタイプまたは他の情報を含む)デバイスプロファイル、および、(多くの異なる顧客環境／配置にわたる)ベースライン／典型的な挙動に基づいている。チャーリーが推奨されたポリシを受け入れる場合には、適切なルール(例えば、図7Bに示されるようなルール)が自動的に作成され(例えば、セキュリティプラットフォーム140による)、そして、実施のためにセキュリティ機器102にインポートされ得る。セキュリティ機器102は、そのネットワーク上のIoTデバイスのデバイスプロファイルを学習し、そして、適用可能なポリシをソースまたは宛先としてのデバイスにマッチさせる。適用可能な場合、ポリシは、ネットワークアクセスコントローラといった、セキュリティ機器102以外のタイプのインフラストラクチャによって使用可能なフォーマットへと(例えば、セキュリティプラットフォーム140によって)変換され得る。
【0080】
以下の説明では、Acmeが、最近、ビルディング自動化デバイスのセット(例えば、バッジリーダのセット)を購入し、それらを様々なAcme施設の内部に設置し、かつ、デバイスをネットワーク110の一部でオンラインに持ち込んだと仮定する。上述のデバイス識別／分類技術を使用して、セキュリティプラットフォーム140は(データアプライアンス102と協働して)、Acmeが28個の新しいバッジリーダデバイスをそのネットワークに追加したことを識別し、そして、Acmeのネットワーク環境内でそれらの特定のバッジリーダデバイスが動作する際(例えば、１週間または１ヶ月の初期観察期間の最中)に取る様々な挙動を学習する。セキュリティプラットフォーム140によって提供される管理インターフェイスの一部が図8に示されている。インターフェイス800は、Acmeが、現在、その環境内で動作している(対応するプロファイルを有する)合計65種類のIoTデバイスを有することを示している。新たに追加されたバッジリーダは、行802に示されている。
【0081】
チャーリーがリンク804をクリックした場合に、彼は、図9に示されるインターフェイスに導かれる。領域902は、セキュリティプラットフォーム140が、28個の新しいデバイスを、高い信頼度でシーメンス・ビルディング・テクノロジー・デバイス（Siemens Building Technology Device）プロファイルに一致するものとして識別したことを示している。Acme環境内で動作している間に28個のデバイスについて収集された挙動情報も、また、示されており、領域904に要約されている。集合的に、28個のデバイスは、Acme環境において8個のアプリケーションを実行し、23個の宛先(Acme内の22個および外部の１個)と通信し、そして、リスクスコア（risk score）の56を、現在、有している。28個のデバイスのうちいくつがAcme環境内の各アプリケーションを使用しているかに係るカウントが、領域906に示されており、そして、宛先（destination）が内部（internal）であるか外部（external）であるかが、領域908に示されている。領域910には、Acme環境内のシーメンス・ビルディング・テクノロジー・デバイスによって使用されるアプリケーションの数が、これらのデバイス(同じシーメンス・ビルディング・テクノロジー・デバイスプロファイルを共有している)が、セキュリティプラットフォーム140の他の顧客の環境にわたり、どのように挙動するかと比較して、含まれている。領域910に示されるように、シーメンス・ビルディング・テクノロジー・デバイスの典型的な顧客展開（customer deployment）は、3個から5個までのアプリケーションを使用し(912)、アクメの展開を典型的な範囲(914)の外側にしている。チャーリーがカーソルを領域912上に置く（hover）と、以下のような、比較に関する追加情報を提供するボックスが、チャーリーに提示される。
「このプロファイルにおいては、8個の異なるアプリケーションが、デバイスによって使用された。全てのIoTセキュリティ顧客からのデータに基づいて、使用されたアプリケーションの最小数は3であり、平均は3であり、そして、最大は5であった。シーメンス・ビルディング・テクノロジー・デバイスによるアプリケーションの使用は、通常よりも高かった。アプリケーションリストをレビューすること。」
「このプロファイルにおいては、8個の異なるアプリケーションが、デバイスによって使用された。全てのIoTセキュリティ顧客からのデータに基づいて、使用されたアプリケーションの最小数は3であり、平均は3であり、そして、最大は5であった。シーメンス・ビルディング・テクノロジー・デバイスによるアプリケーションの使用は、通常よりも高かった。アプリケーションリストをレビューすること。」
【0082】
チャーリーは、インターフェイス900をさらに下にスクロールすることによって、アプリケーションリストをレビューすることができる。図10に示されるように、チャーリーは、そうしたスクロールの後で、「dhcp」および「bacnet」アプリケーションのバッジリーダデバイスによる使用をレビューしている。「使用（“usage”）」指定（designation）(1002)は、プロファイルを共有しているIoTデバイスについてネットワーク使用パターン(デバイスプロファイル＋アプリケーション＋URL(例えば、“www.siemens.com/update”)の頻度、及び／又は、宛先プロファイル(例えば、「PACSサーバ」)の頻度を示している。様々な実施形態において、各アプリケーションの使用は、最初に収集されたトラフィックの１ヶ月に基づいて生成される。チャーリーは、所定の挙動を許可するか、または、ブロックするかを決定する際に、使用情報を使用することができる。例えば、彼は、bacnetがまれにしか使用されない場合、それは、内部ドメインの中だけで許可され、または、既定の外部ドメインに対してだけ許可されるべきであることを、(例えば、Acmeの環境に係る彼の知識に基づいて)学習することができる。
【0083】
チャーリーがインターフェイス900の領域916をクリックした場合には、バッジリーダ装置に適用できるポリシのセットを作成するための2個のオプションが、彼に提示される。前述のように、チャーリーは、バッジリーダデバイスについて、(例えば、インターフェイス900の実施形態に係る様々な要素と対話することによって)彼自身のポリシセットを手動で作成することができる。チャーリーは、また、セキュリティプラットフォーム140の他の顧客の環境から取得されたベースライン／他の情報を使用して、セキュリティプラットフォーム140が生成した、推奨ポリシセットをロードすることを選択することもできる。一旦、領域916をクリックし、かつ、(利用可能な場合)推奨ポリシセットを使用することを選択すると、セキュリティプラットフォーム140は、任意の利用可能な推奨ポリシセットを列挙し、そして、チャーリーは、(例えば、インターフェイス800によって提供される様々な機能と対話することによって)適用可能なポリシを改良／調整する能力を用いて、それらをAcme環境にダウンロード／適用することができる。
【0084】
図11は、IoTデバイスを伴う通信に対して適用するポリシを生成するためのプロセスに係る一つの例を示している。様々な実施形態において、プロセス1100は、セキュリティプラットフォーム140によって実行される。プロセス1100は、また、適用可能な他のシステム(例えば、IoTデバイスとオンプレミスで共配置（collocated）されたシステム)によっても実行され得る。プロセス1100は、IoTデバイスのネットワーク通信に関連付けられた情報が受信されると、1102において開始する。一つの例として、そうした情報は、データアプライアンス102が所与のIoTデバイス(例えば、バッジリーダデバイス)についてのデバイス発見イベントを送信するときに、セキュリティプラットフォーム140によって受信される。1104において、受信された情報は、IoTデバイスと関連付けるためのデバイスプロファイルを決定するために使用される。一つの例として、IoTデバイスが、特定のシリアル／MACアドレス、特定のIPアドレス、等を有している、シーメンスSIMATEC RF10000デバイスであるという決定が行われる。この例において、決定された「デバイスタイプ（“device type”）」は、「シーメンス・ビルディング・テクノロジー・デバイス」であり得る。このセクションにおいて、デバイスタイプ（例えば、バッジリーダデバイス）と、デバイスプロファイル（例えば、シーメンス・ビルディング・テクノロジー・デバイス）とは、互換可能に、一般的に参照されている。しかしながら、複数のプロファイルが、所与のデバイスタイプ(例えば、Acmeのリサーチエリア対（vs.）Acmeの小売エリアにおいて置かれたシーメンス・ビルディング・テクノロジー・デバイス)について作成され、そして、所与のプロファイルが、適用可能な場合、複数のデバイスタイプを含むことができる(例えば、シーメンス・ビルディング・テクノロジー・デバイスプロファイルは、バッジリーダデバイスおよびモーショントリガセンサを含むことができる)。最終的に、1106において、セキュリティ機器によってIoTデバイスに適用されるべき推奨ポリシが生成される。一つの例として、図9に示される8個のアプリケーション全てに対するアクセスを許可する代わりに、セキュリティ機器140は、領域910に示される情報に対応している3個の最も一般的に使用されるバッジリーダアプリケーション(または、5個の最も一般的に使用されるバッジリーダアプリケーション)だけを許可する、ポリシセットを推奨することができる。一旦、推奨されるポリシをダウンロードし、かつ、適用すると、チャーリーが推奨されるセットに対して調整(例えば、ホワイトリストbacnet)を行う必要がある場合に、彼は、(例えば、インターフェイス800によって提供される「編集（“edit”）」オプションと対話することによって)調整を行うことができる。
【0085】
前述の実施形態は、理解を明確にする目的で、ある程度詳細に説明されてきたが、本発明は、提供された詳細に限定されるものではない。本発明を実施する多くの代替方法が存在している。開示された実施形態は、例示的であり、かつ、限定的なものではない。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図2F】
【図2G】
【図3】
【図4A】
【図4B】
【図4C】
【図5】
【図6】
【図7A】
【図7B】
【図8】
【図9】
【図10】
【図11】
【国際調査報告】