IOT安全中基于模式匹配的检测

摘要

公开了用于提供物联网（IoT）安全的技术。一种适用的系统包括对IoT设备进行剖析以限制适用于IoT设备的网络签名的数量，并使用对于给定IoT设备的简档而言适当的模式来执行模式匹配。

说明书

附图说明

图1描绘了用于物联网（IoT）安全中基于模式匹配的检测的系统的示图；

图2描绘了用于IoT安全中基于模式匹配的检测的方法的示例的流程图；

图3描绘了包括镜像网关的IoT设备活动生成系统的示例的示图；

图4描绘了包括本地化代理的IoT设备活动生成系统的示例的示图；

图5描绘了IoT设备活动抽取系统的示图；

图6描绘了IoT设备活动模式匹配系统的示图；

图7描绘了IoT设备剖析系统的示例的示图。

具体实施方式

图1描绘了用于物联网（IoT）安全中基于模式匹配的检测的系统的示例的示图100。示图100包括计算机可读介质（CRM）102、耦合到CRM 102的IoT设备104-1……104-h（统称为“IoT设备104”）、耦合到CRM 102的IoT设备活动生成引擎106、耦合到CRM 102的网络活动数据存储108、耦合到CRM 102的IoT设备剖析引擎110、耦合到CRM 102的IoT设备简档数据存储112、耦合到CRM 102的IoT设备活动模式匹配引擎114以及耦合到CRM 102的活动模式数据存储116。

本文章中讨论的CRM 102和其他计算机可读介质旨在表示各种潜在的适用技术。例如，CRM 102可以用于形成网络或网络的一部分。在两个组件共同位于一个设备上的情况下，CRM 102可以包括总线或其他数据管道或平面。在第一组件位于一个设备上并且第二组件位于不同设备上的情况下，CRM 102可以包括无线或有线后端网络或LAN。如果适用，CRM102还可以涵盖WAN或其他网络的相关部分。

本文章中讨论的计算机可读介质旨在包括所有法定介质（例如，在美国，按照35U.S.C. 101），并明确排除性质上非法定的所有介质——在该排除对于包括计算机可读介质的权利要求有效而言是必要的程度上。已知的法定计算机可读介质包括硬件（例如，寄存器、随机存取存储器（RAM）、非易失性（NV）存储装置，仅举几例），但是可以或可以不限于硬件。

本文章中描述的设备、系统和计算机可读介质可以实现为计算机系统或计算机系统的部分或多个计算机系统。一般而言，计算机系统将包括处理器、存储器、非易失性存储装置和接口。典型的计算机系统通常将至少包括处理器、存储器、以及将存储器耦合到处理器的设备（例如，总线）。处理器可以是例如通用中央处理单元（CPU）、诸如微处理器，或者专用处理器、诸如微控制器。

作为示例而非限制，存储器可以包括随机存取存储器（RAM），诸如动态RAM（DRAM）和静态RAM（SRAM）。存储器可以是本地的、远程的或分布式的。总线还可以将处理器耦合到非易失性存储装置。非易失性存储装置经常是磁软盘或硬盘、磁光盘、光盘、只读存储器（ROM）（诸如CD-ROM、EPROM或EEPROM）、磁卡或光卡或用于大量数据的另一种形式的存储装置。在计算机系统上执行软件期间，该数据中的一些经常通过直接存储器存取处理被写入存储器中。非易失性存储装置可以是本地的、远程的或分布式的。非易失性存储装置是可选的，因为可以利用存储器中所有适用的数据来创建系统。

软件典型地存储在非易失性存储装置中。事实上，对于大型程序而言，可能甚至不可能将整个程序存储在存储器中。然而，应当理解的是，为了软件运行，如果必要，它被移动到对于处理而言适当的计算机可读位置，并且为了说明的目的，该位置在本文章中被称为存储器。即使当软件被移动到存储器以供执行时，处理器典型地也将利用硬件寄存器来存储与软件相关联的值，并利用理想地服务于加速执行的本地高速缓存。如本文所使用的，当软件程序被称为“在计算机可读存储介质中实现”时，软件程序被假设存储在适用的已知或方便的位置处（从非易失性存储装置到硬件寄存器）。当与程序相关联的至少一个值存储在处理器可读的寄存器中时，处理器被认为是“被配置为执行程序”。

在操作的一个示例中，计算机系统可以由操作系统软件控制，操作系统软件是包括文件管理系统（诸如磁盘操作系统）的软件程序。具有相关联的文件管理系统软件的操作系统软件的一个示例是来自华盛顿州雷蒙德市的微软公司的操作系统家族（已知为Windows®），及其相关联的文件管理系统。操作系统软件及其相关联文件管理系统软件的另一个示例是Linux操作系统及其相关联的文件管理系统。文件管理系统典型地存储在非易失性存储装置中，并使得处理器执行操作系统输入和输出数据以及将数据存储在存储器中（包括将文件存储在非易失性存储装置上）所需的各种动作。

总线还可以将处理器耦合到接口。该接口可以包括一个或多个输入和/或输出（I/O）设备。取决于特定于实现的考虑或其他考虑，作为示例而非限制，I/O设备可以包括键盘、鼠标或其他定点设备、磁盘驱动器、打印机、扫描仪和其他I/O设备，包括显示设备。作为示例而非限制，显示设备可以包括阴极射线管（CRT）、液晶显示器（LCD）或一些其他适用的已知或方便的显示设备。所述接口可以包括调制解调器或网络接口中的一个或多个。应当领会，调制解调器或网络接口可以被认为是计算机系统的一部分。该接口可以包括模拟调制解调器、ISDN调制解调器、线缆调制解调器、令牌环接口、卫星传输接口（例如，“直接PC”）或用于将计算机系统耦合到其他计算机系统的其他接口。接口使得计算机系统和其他设备能够在网络中耦合在一起。

计算机系统可以与基于云的计算系统兼容，或者作为基于云的计算系统的一部分或通过基于云的计算系统来实现。如本文章中所使用的，基于云的计算系统是一种向终端用户设备提供虚拟化计算资源、软件和/或信息的系统。计算资源、软件和/或信息可以通过维护边缘设备可以通过诸如网络的通信接口访问的集中式服务和资源来虚拟化。“云”可以是一个营销术语，并且出于本文章的目的，可以包括本文所述的任何网络。基于云的计算系统可以涉及对服务的订阅或者使用效用定价模型。用户可以通过位于其终端用户设备上的web浏览器或其他容器应用来访问基于云的计算系统的协议。

计算机系统可以作为引擎、作为引擎的部分或通过多个引擎来实现。如本文章中所使用的，引擎包括一个或多个处理器或其一部分。一个或多个处理器的一部分可以包括少于包括任何给定的一个或多个处理器的所有硬件的一些硬件部分，诸如寄存器的子集、专用于多线程处理器的一个或多个线程的处理器部分、其间处理器全部或部分专用于实行部分引擎功能性的时间切片等等。照此，第一引擎和第二引擎可以具有一个或多个专用处理器，或者第一引擎和第二引擎可以彼此或与其他引擎共享一个或多个处理器。取决于特定于实现的考虑或其他考虑，引擎可以是集中式的，或者其功能性是分布式的。引擎可以包括体现在计算机可读介质中的硬件、固件或软件以供处理器执行。处理器使用诸如参考本文章中的各图所描述的所实现数据结构和方法将数据变换成新的数据。

本文章中所描述的引擎或者可以通过其实现本文章中所描述的系统和设备的引擎可以是基于云的引擎。如本文章中所使用的，基于云的引擎是可以使用基于云的计算系统运行应用和/或功能性的引擎。应用和/或功能性的全部或部分可以跨多个计算设备分布，并且不需要局限于仅一个计算设备。在一些实施例中，基于云的引擎可以执行终端用户通过web浏览器或容器应用访问的功能性和/或模块，而不必将功能性和/或模块本地安装在终端用户的计算设备上。

如本文章中所使用的，数据存储旨在包括具有任何适用的数据组织的储存库，包括表格、逗号分隔值（CSV）文件、传统数据库（例如，SQL），或其他适用的已知或方便的组织格式。例如，数据存储可以实现为体现在专用机器上的物理计算机可读介质中的软件中、固件中、硬件中、其组合中、或者适用的已知或方便的设备或系统中。与数据存储相关联的组件（诸如数据库接口）可以被视为“数据存储的一部分”、“一些其他系统组件的一部分”或其组合，尽管与数据存储相关联的组件的物理位置和其他特性对于理解本文章中所述技术而言并非是关键的。

数据存储可以包括数据结构。如本文章中所使用的，数据结构与在计算机中存储和组织数据的特定方式相关联，使得其在给定的上下文中被高效地使用。数据结构一般基于计算机在其存储器中由地址指定的任何地方处取得和存储数据的能力，所述地址即本身可以存储在存储器中并由程序操控的位串。因此，一些数据结构是基于利用算术运算计算数据项的地址；而其他数据结构是基于在结构本身内存储数据项的地址。许多数据结构使用这两个原理，有时以非平凡的方式组合。数据结构的实现通常需要编写一组过程来创建和操控该结构的实例。本文章中描述的数据存储可以是基于云的数据存储。基于云的数据存储是与基于云的计算系统和引擎兼容的数据存储。

返回到图1的示例，IoT设备104旨在表示被有目的地构建或配置的IoT设备。IoT设备的示例包括恒温器、移动设备、生物管理器、传感设备和功能性执行设备。在被有目的地构建的IoT设备中，IoT设备104被构建为具有特定的操作参数。例如，可以构建温度计来提供来自温度传感器的信号。在被有目的地配置的IoT设备中，IoT设备104可以被配置为依照根据来自人类或人工代理的输入的特定操作参数进行操作。例如，IoT设备104的IoT设备可以是恒温器，其被配置为控制空调在可配置的时间处将房间冷却到可配置的温度。作为另一个示例，作为有目的配置的一部分，代理可以指定IoT设备不应当与特定数据源通信，并且IoT设备可以被配置为抑制与该特定数据源通信。

在特定实现中，IoT设备104包括有线或无线接口，IoT设备104可以通过所述接口通过有线和无线连接发送和接收数据。如本文章中所使用的，术语“实现”意味着用于作为示例而不一定作为限制地说明的实现。IoT设备104可以具有可以在通过网络传输数据中使用的唯一标识符。IoT设备104的唯一标识符可以包括根据因特网协议版本4（下文称为“IPv4”）创建的标识符，或者根据因特网协议版本6（下文称为“IPv6”）创建的标识符，这两个协议版本特此通过引用而并入。取决于特定于实现的考虑或其他考虑，IoT设备104可以包括适用的通信接口，用于根据适用的无线设备协议接收和发送数据。适用的无线设备协议的示例包括Wi-Fi、ZigBee®、蓝牙®和其他适用的低功率通信标准。

在特定实现中，IoT设备104充当站。如本文章中使用的站可以被称为具有媒体访问控制（MAC）地址和到符合IEEE 802.11标准的无线介质的物理层（PHY）接口的设备。因此，例如，如果适用，则网络设备可以被称为站。IEEE 802.11a- 1999、IEEE 802.11b-l999、IEEE 802.11g-2003、IEEE 802.11-2007和IEEE 802.11h TGn草案8.0（2009）通过引用并入。如本文章中所使用的，兼容802.11标准或符合802.11标准的系统符合并入文档的要求和/或建议或者来自文档早期草稿的要求和/或建议中的一个或多个中的至少一些，并且包括Wi-Fi系统。Wi-Fi是一种非技术描述，其一般与IEEE 802.11标准、Wi-Fi保护接入（WPA）和WPA2安全标准以及可扩展认证协议（EAP）标准相关。在替代实施例中，站可以符合不同于Wi-Fi或IEEE 802.11的标准，可以被称为除“站”之外的某一名称，并且可以具有到无线或其他介质的不同接口。

在特定实现中，IoT设备104被配置为遵循IEEE 802.3访问网络服务。IEEE 802.3是由定义有线以太网物理层和数据链路层的MAC的工作组产生的工作组和IEEE标准集合。这一般是一种具有一些广域网应用的局域网技术。物理连接典型地通过各种类型的铜线缆或光纤线缆在节点和/或基础设施设备（集线器、交换机、路由器）之间进行。IEEE 802.3是支持IEEE 802.1网络架构的技术。如相关领域中众所周知的，IEEE 802.11是用于在2.4、3.6和5 GHz频带中实现无线局域网（WLAN）计算机通信的工作组和标准集合。标准IEEE802.11-2007的基础版本已有后续修订。这些标准为使用Wi-Fi品牌的无线网络产品提供了基础。IEEE 802.1和802.3通过引入并入。

在特定实现中，IoT设备104具有相应的个性。如本文章中所使用的，个性是行为的集合；行为用于描述特定类型的设备。如本文章中所使用的，行为是应用驱动的一个或多个相关活动的集合。个性可能是不良的，这意味着该个性是可标识为属于如下设备的个性：该设备展现出不合期望的行为或具有稍后展现出不合期望的行为的不可接受的风险。个性可能是良好的，这意味着个性是可标识为属于如下设备的个性：该设备尚未并且预期不会在稍后展现出不合期望的行为。设备可能展现出异常行为，并且异常检测是用以确定设备是否正在展现出不合期望的行为的有用工具，因此异常行为有时与不合期望的行为相关联。然而，随着时间的推移，异常行为可能指示尚未标识但潜在地良好的个性。如果具有第一个性的设备展现出异常行为，则定义第二个性可以是可能的，第二个性以一些方式类似于第一个性，但是对于第二个性而言，某种行为并不异常。类似地，随着时间的推移，第一个性可以被更好地定义为包括先前异常行为作为非异常行为。因此，可以合期望的是，提供不仅可以将IoT设备分类为具有各种个性的系统，而且还提供可以允许个性具有可延展的定义并且可以随着时间的推移定义新的个性的系统。

IoT设备活动生成引擎106旨在表示使用IoT设备相关事件生成IoT设备活动数据结构的系统。在特定实现中，IoT设备活动生成引擎106与IoT设备104在同一LAN上。例如，IoT设备活动生成引擎106可以被实现为在IoT设备104的家中和/或在被配置为通过LAN向IoT设备104提供对网络服务的访问的本地设备处形成LAN的一部分的本地设备。替代地或附加地，IoT设备活动生成引擎106或其一部分可以被实现为私有云的一部分。实现IoT设备活动生成引擎106或其至少一部分的私有云可以特定于实体。

在特定实现中，IoT设备活动生成引擎106起作用来使用相对于IoT设备104是本地的事件来生成活动。在使用相对于IoT设备是本地的事件来生成活动中，IoT设备活动生成引擎106可以在与IoT设备相关联或部分通过IoT设备形成的LAN内的设备处实现。IoT设备活动生成引擎106可以从与LAN内的设备相关联的事件中生成活动数据结构，以用于后续在确定IoT设备的行为对于IoT设备的简档是否适当中使用。例如，IoT设备活动生成引擎106可以在本地代理处实现，并在本地代理处确定事件以供在标识IoT设备操作中相对于IoT设备简档的不期望的行为中使用。

事件的重要子类是网络会话事件或“网络事件”。在一些实现中，网络事件可以被适当地称为“基于分组的”（或“基于帧的”）事件，因为网络事件捕捉是以分组或帧的形式。在特定实现中，离散网络事件是网络会话。可替代地或附加地，离散网络事件是已经被分成组块的持久网络会话的一部分，其中网络会话的组块聚合起来包括网络会话。

网络活动数据存储108旨在表示活动数据结构的数据存储。在特定实现中，网络活动中的至少一些包括与IoT设备104之一相关联的变换事件的表示。如本文章中所使用的，活动数据结构是经标记的事件的集合。活动数据结构可以包括不是网络事件的事件的表示，诸如本地数据库访问事件或者经由活动查询从（多个）日志消息获得的事件等。有利的是，稍后更详细地描述的模式匹配可以用在具有包括网络事件和非网络事件这两者的活动数据结构的活动上。

在操作示例中，IoT设备活动生成引擎106对网络活动数据存储108执行创建、读取、更新或删除（CRUD）。稍后诸如例如参考图3更详细地描述事件变换。

因为IoT设备104的IoT设备的网络会话是网络事件（或者持久网络会话可以被“分块”成一系列网络事件），所以IoT设备可以被标识为由网络活动数据存储108中的活动数据结构定义的活动中的参与者，该活动数据结构包括网络事件的表示。在其中给定IoT设备简档的实现中，模式匹配可以考虑IoT设备的简档，以将活动模式限制为已经被标识为最相关的活动模式。例如，可以为运行在windows上的医学设备生成活动模式，这使得针对模式匹配目的，如二进制windows下载或者远程RPC连接等这样的活动是最为相关的。作为另一个示例，模式可以与应用相关联，应用诸如将图像发送到云以用于安全设备，其不同于医学成像设备。诸如流式传输、文件上传、管理等各种活动对于不同的简档是不同的。由于大量的可能性，在没有以合理的准确性对IoT设备进行剖析的情况下，将几乎不可能完成本文章中描述的一些目标。剖析使得计算资源能够更有选择性地应用于活动的活动模式匹配（这本身比匹配简单的特征要困难得多，诸如，在出于检测恶意软件的目的而执行模式匹配时使用其的成功率有限）。

IoT设备剖析引擎110旨在表示用于剖析或促进IoT设备104的剖析的引擎。IoT设备可以被剖析为恒温器、X-光机器、运动传感器或某种其他类型的设备。剖析可以先于IoT设备的部署发生。例如，即使运动传感器IoT设备尚未部署在适用的LAN中，运动传感器简档也可以存在于IoT设备简档数据存储112中。IoT设备剖析引擎110可以在IoT设备部署之前，诸如通过向网络管理员注册该IoT设备，来促进由人类或人工代理进行剖析。剖析可以包括从包括关于相关IoT设备的信息的本地或远程数据存储（诸如从公共源、服务提供商或其他方）获得简档信息。剖析还可以包括IoT设备简档的特征的手动录入。

在一些网络中，新的IoT设备的部署发生得相对频繁，使得难以进行准确的预剖析。因此，在特定实现中，IoT设备剖析引擎110分析与还未被剖析的任何IoT设备104相关联的数据，以理想地确保IoT设备104中的每一个被剖析。在特定实现中，已经被剖析的IoT设备104中的每一个具有唯一的简档。在替代方案中，IoT设备104的子集可以具有多个临时简档，其中的一些可以随着时间的推移被消除以获得一个且仅一个简档，对于IoT设备104的子集，该简档将不再被称为“临时的”。剖析和消除临时简档可以通过事件分析以与稍后描述的模式匹配非常相同的方式来完成，但是应当注意，从相对大量的临时简档开始可能在计算上是禁止的。因此，IoT设备剖析引擎110必须具有某种智能，或者依赖于人类或人工代理的智能，从而使得IoT设备剖析引擎110能够缩小每个IoT设备的潜在简档的范围。例如，IoT设备剖析引擎110可以从IoT设备MAC地址标识制造商，并查阅与所标识的制造商相关联的数据存储以确定制造商使用什么类型的设备。

如果计算资源可用并且期望消耗资源，则可以使用一些计算上昂贵的技术，诸如深度分组检测（DPI）。一种更具成本效益的技术是要限制LAN上允许的IoT设备简档的数量，并假设IoT设备具有所有允许的临时简档，直到如可以更准确地剖析IoT设备的这样的时间为止。如果IoT设备剖析引擎110需要时间来剖析IoT设备，则在IoT设备剖析引擎110试图剖析IoT设备时，未知IoT设备隔离引擎（未示出）可以至少暂时地干扰IoT设备操作。

在操作的示例中，IoT设备剖析引擎110在IoT设备简档数据存储112中存储简档，该简档可以或可以不包括临时简档。在特定实现中，简档先于至少一个IoT设备104的部署被存储，并且是相对静态的。相对静态意味着，人类或人工代理必须在一时间段内修改IoT设备简档数据存储112，这将灾难性地影响用于尚未剖析的IoT设备的IoT设备功能的至少某个方面，或者将允许IoT设备在没有首先被剖析的情况下操作（后者可以被表征为给未知设备一个“默认”简档）。例如，如果在给定的时间跨度内，IoT设备剖析引擎110未能将IoT设备与IoT设备简档数据存储112中的简档相匹配，则网络管理员可以接收到提示网络管理员采取与对尚未剖析（或“默认”剖析）的IoT设备的剖析相关联的动作的警报，这可以包括向IoT设备简档数据存储112添加新的简档。IoT设备104被链接到IoT设备简档数据存储112中的适用简档。至少在概念上，IoT设备与其简档的关联被假设为IoT设备简档数据存储112的一部分，尽管定义这样的关联的信息也可以被包括在IoT设备数据存储（未示出）中。

基于IoT设备的特性、IoT设备的操作特性和IoT设备在其中操作的环境的特性中的一个或组合，IoT设备可以被分组在一起以形成简档。例如，特定制造商的所有恒温器IoT设备可以被分组在一起以形成简档。一般而言，IoT设备剖析引擎110使用可标识为对剖析处理有用的任何数据来剖析IoT设备104，该数据诸如（典型地是源或目的地的）MAC地址、IP地址、分组大小、UID等。取决于特定于实现的考虑或其他考虑，简档包括组中IoT设备的正常操作行为模式、组中IoT设备的不期望的操作行为模式或这两者。

在图1的示例中，IoT设备活动模式匹配引擎114旨在表示一系统，该系统用于通过如下方式确定被包括在网络活动数据存储108中的IoT设备104的活动对于如存储在IoT设备简档数据存储112中的分别归属于IoT设备104的简档是否适当：将具有第一简档的IoT设备104的第一子集的活动与活动模式数据存储116中与第一简档相关联的第一模式子集相匹配，具有第二简档的IoT设备104的第二子集的活动与活动模式数据存储116中与第二简档相关联的第二模式子集相匹配，以此类推到第n子集和简档。匹配预期模式来确定IoT设备功能正如预期等同于未能匹配到意外模式，但本文章中一般以如下方式理解使用术语“匹配”：上下文将确定A等于B是匹配还是A不等于B是匹配。在本文章中使用的“不匹配”或等同物的程度上，其一般将是出于可读性的目的，具有与前一句中阐述的相同的理解。

在示图100中，IoT设备活动模式匹配引擎114包括IoT设备预期行为模式匹配（子）引擎118、IoT设备异常行为模式匹配（子）引擎120、活动标识（子）引擎122和威胁检测（子）引擎124。然而，可以注意到，模式的匹配可以不可知地完成，使得没有必要出于模式匹配的目的而实现单独的引擎；在典型实现中，IoT设备预期行为模式匹配引擎118和IoT设备异常行为模式匹配引擎120仅在概念上不同。不期望的行为被机构或安全系统定义为不合期望的。可以注意到，具有良好个性的IoT设备可以展现出异常行为并且仍然被认为具有良好个性，而具有不良个性的IoT设备不需要展现出异常行为并且仍然被认为具有不良个性。这是值得注意的，因为用于标识不期望的行为的技术可以包括异常检测，但是异常检测不是不期望的行为检测的全部。因此，在特定实现中，模式匹配包括与正常行为模式、异常行为模式或这两者相关联的模式的应用。如本文章中所使用的，个性包括数学建模的行为模式，其中机构知识被构建到个性模型中。不良个性的示例包括与网上机器人、C&C中心（僵尸网络）或被恶意软件接管的服务器（仅举三例）相关联的行为，所有这些都可能具有可识别的行为。

在特定实现中，IoT设备预期行为模式匹配引擎118出于如下目的将来自活动模式数据存储116的模式应用于网络活动数据存储108的活动数据结构：确定检测到的IoT设备功能是否落入IoT设备简档数据存储112中已被归属于该IoT设备的简档的可接受参数内。如果相关简档具有多于一个的相关联模式，则IoT设备预期行为模式匹配引擎118将第二模式应用于IoT设备事件，以此类推，直到每个模式都已被应用。如果IoT设备的行为与可归属于该IoT设备的简档的模式中的每一个都不匹配，则IoT设备预期行为模式匹配引擎118生成警报。警报可以具有不同的权重，这可以取决于特定于实现的考虑或其他考虑而变化。低优先级警报可以被表征为与（在当下）被认为是良性的行为相关联的警报。等同地，IoT设备预期行为模式匹配引擎118可以将与模式的偏差视为在可接受的参数内，并且不生成明确的警报。高优先级警报可以被表征为与被认为是恶意或有风险的行为相关联并触发自动对策的警报。

在特定实现中，IoT设备预期行为模式匹配引擎118协助IoT设备剖析引擎110利用默认或临时简档来剖析IoT设备。例如，IoT设备预期行为模式匹配引擎118可以使用可标识的历史行为、至少部分地使用网络活动数据存储108中的活动数据结构，通过简档层级来发挥作用，直到找到适当的匹配，所述匹配被提供回IoT设备剖析引擎110以协助剖析IoT设备。可以组织简档的层级，使得首先假设最可能的候选简档。

在特定实现中，IoT设备异常行为模式匹配引擎120出于如下目的将模式应用于IoT设备事件：确定IoT设备功能是否落在可归属于该IoT设备的简档的可接受参数之外。如果相关简档具有多个相关联模式，则IoT设备异常行为模式匹配引擎120将第二模式应用于IoT设备行为，以此类推，直到每个模式都已经被应用。如果IoT设备的行为与可归属于该IoT设备的简档的模式中的任何一个相匹配，则IoT设备异常行为模式匹配引擎120生成警报。出于说明目的，当所记录的IoT设备行为指示异常行为时，匹配异常行为模式。如先前所指示的，警报可以具有取决于多个因素的可变权重，其中与可能仅指示尚未被并入到模式中的可接受操作的行为相比，对偏离策略的标识或对与恶意IoT设备相关联的行为的标识一般更值得更高的权重。

活动标识引擎122能够标识由活动生成引擎106生成和/或存储在网络活动数据存储108中的活动。

威胁检测引擎124可以使用无监督学习（基于聚类的算法、基于分区的算法、基于神经网络的算法等）来发现威胁。

在操作的示例中，IoT设备活动模式匹配引擎114的引擎将网络活动数据存储108中的活动数据结构仅与活动模式数据存储116中的模式子集相匹配，该子集与IoT简档数据存储112中归属于与活动数据结构相关联的IoT设备的简档相关联。如果存在模式匹配（或等同地，匹配失败），则可以或可以不生成警报。一般而言，安全风险越严峻，将生成警报的可能性就越大。

图2描绘了用于将IoT设备行为匹配到与可归属于IoT设备的简档相关联的模式子集的方法的示例的流程图200。在本文章中描述的流程图200和其他流程图具有可以依次重新排序或重组成并行序列的模块（如果适用的话）。流程图200在模块202处开始，其中（模式超集的）第一模式子集与多个IoT设备简档中的第一IoT设备简档相关联。有利的是，通过将模式匹配引擎限制为与给定简档相关联的模式，将所需的计算减少到使得模式匹配到IoT设备活动在实践中有用的水平是可能的。事实上，随着IoT网络在大小方面增加并且IoT设备类型的数量级增长，甚至将有可能扩展。

流程图200继续到模块204，其中第一IoT设备简档归属于第一IoT设备。在简单的场景中，第一IoT设备简档可以在部署之前由网络管理员归属于第一IoT设备。然而，IoT网络可以是动态的，使得在IoT设备被部署之后对它们进行剖析是合期望的，这可以包括将IoT设备的行为与默认的IoT设备简档进行模式匹配，并使用可用数据（理想地）快速剖析尚未剖析的IoT设备。在检测到后立即或在其期间试图进行剖析的宽限时段之后，针对所有尚未剖析的IoT设备进行隔离或以其他方式部署对策可以是合期望的。

流程图200继续到模块206，其中检测第一IoT设备事件，其包括第一IoT设备的一个或多个网络会话。在特定实现中，经由被动监视来检测事件。一种相当平凡类型的检测到的事件可能是去往或来自第一IoT设备的消息。聚焦于检测花费相对较少资源来表征的离散事件（诸如分组报头中的信息）可以是合期望的，尽管可以使用其他更资源密集型的技术（诸如DPI），来获得甚至更多的事件数据。

流程图200继续到模块208，其中从第一IoT设备事件和其他事件生成活动数据结构。生成活动数据结构的一方面是抽取，这需要丢失与事件相关联的数据，以便于对与IoT设备相关联的活动的更有用的表征。活动可以被定义为经标记的事件集合，之所以经标记是因为它已经被证明有价值。抽取可以涉及对事件进行限定的技术，诸如聚合、充实和转化。聚合事件的相当平凡的示例是由第一IoT设备定期传输并被视为复合（聚合）事件的心跳消息集合。然而，聚合事件可以更复杂得多，并且甚至合并有将不一定与第一IoT设备相关联，而是用于确定第一IoT设备和否则不相关的事件之间的相关性已经被标识的数据。在特定实现中，使用机器学习将离散事件聚合以形成复合事件。公共因素聚合是一种通过聚焦于如应用于检测到的行为和所建模的行为这两者的公共因素（如相同简档、相同OS、使用Windows、使用telnet的所有设备，所有与特定子网讲话的设备，仅举几例），来应用各种不同的机器学习和深度学习算法的方式。例如，会话事件可以聚合在一起。在另一个示例中，流式传输事件可以聚合在一起。可以相对于第一IoT设备在本地聚合事件。例如，事件可以由被实现为具有第一IoT设备的LAN的一部分的设备聚合以形成聚合事件。应当注意的是，在本文章中，经标记的聚合事件可以被称为“活动”，但是更一般地，活动是经标记的一个或多个事件的集合，所述事件可以是离散的或聚合的。充实涉及将数据（潜在地包括其他事件）与事件相关联。转化涉及将原始事件数据转换成更适合活动表征的格式。

流程图200继续到模块210，其中第一模式子集被应用于活动。该活动充当第一IoT设备的签名（的一部分）。模式受第一简档限制。例如，运行在Windows®上的医学设备的简档的模式可以包括二进制windows下载模式和来自医学设备模式的远程RPC连接，这对于与安全相机IoT设备签名进行比较而言将是不必要的模式，对于安全相机IoT设备签名而言，与向云发送图像相关联的模式可能更适当。正则表达式是定义模式的一种方式，但是也可以使用其他方式，并且在特定实现中，至少一种模式不服从使用正则表达式来定义。应当注意的是，模式可以映射到物理层活动，并且照此，与更高层事件、活动（特别是当被定义为经标记的事件集合时）和行为（特别是当被定义为一个或多个相关活动的应用驱动的集合时）相比，模式可以在行为的层级表示中被表征为更低。然而，在特定实现中，模式被映射到活动。

在概念上，模式可以被表征为检测简档的相关活动，诸如流式传输、文件上传或者管理等，连同特征和/或主导趋势（例如，对于安全相机而言，流式传输是主导的）。在特定实现中，全体活动被提取到相对小的集合中（例如，定义的活动可以限于一百个或更少的一般人类可读的聚合事件，诸如登录、认证、更新请求、下载、安装等）。在特定实现中，多个轻量级引擎聚焦于相应的多个活动（例如，下载）或活动的相对常见的子集（例如，Windows®下载）。因为第一IoT设备已经被剖析，并且第一模式子集是所有可能模式的可管理子集，所以近乎实时地将IoT设备签名与已知的可接受或不可接受签名进行比较成为可能。有利的是，尽管不能应用完整的模式库，但是因为首先剖析IoT设备，所以在保持精度的同时更有选择性是可能的。

流程图200继续到模块212，其中当第一模式子集对活动的应用指示不合期望的行为时，生成警报。值得注意的是，将活动映射到期望的行为也可能是有利的，但是本文章中描述的技术的预期实现是针对IoT网络安全的，这将有可能包括在检测到不合期望的行为时的警报生成。不合期望的行为可能包括异常行为或具有不良个性的IoT设备的正常行为。

图3描绘了包括镜像网关的IoT设备活动生成系统的示例的示图300。示图300包括LAN 302、IoT设备网关304、WAN 308、数据管道310、镜像数据管道312、IoT设备事件检测引擎314、IoT设备事件数据存储316、IoT设备事件到活动生成引擎318、IoT设备活动数据存储320和IoT设备简档数据存储322。

LAN 302旨在表示IoT设备（以及潜在的其他设备）的相对本地的网络。应当注意的是，企业网络可以包括在地理上分布式的LAN，其跨WAN分段耦合。在分布式企业网络中，与IoT设备网关304相当的本地网关可以在每个LAN处是本地的（在IEEE 802.11用语中，每个LAN有时被称为基本服务集（BSS），尽管这里没有暗示明确的要求），或者使用例如VLAN隧道本地化（在IEEE 802.11用语中，连接的LAN有时被称为扩展服务集（ESS），尽管这里没有暗示明确的要求），尽管在地理上分布式企业网络中，连接各种LAN一般仍然需要某种形式的网关功能性。

IoT设备网关304旨在表示LAN 302和WAN 306之间的网关。在图300中，IoT设备网关306包括镜像端口306。在特定实现中，IoT设备网关304能够在一些IoT设备业务和非IoT设备业务之间进行区分，并且镜像少于全部的总业务，具体而言，镜像时排除至少一些非IoT设备业务。替代地或附加地，可以存在所实现的多个网关，其中一个是IoT设备网关304，并且其中一个是非IoT设备网关（未示出）。当然，不在IoT设备业务和非IoT设备业务之间进行区分的不可知网关在实现上是直接的；这样的实现将使得IoT设备事件检测引擎314完全或至少在执行IoT设备特定任务时忽略考虑非IoT设备业务。

WAN 308旨在表示因特网，它至少包括在负责管理LAN 302的企业（或其他实体）的控制之外的某个硬件。

数据管道310旨在表示CRM，通过该CRM，业务从LAN 302通过IoT设备网关304发送到耦合至WAN 308的目的地，并从耦合到WAN 308的源通过IoT设备网关304发送到LAN 302上的IoT设备。

镜像数据管道312旨在表示CRM，通过该CRM，来自数据管道310的至少一部分业务被复制。IoT设备网关304的镜像端口306镜像数据管道310上的至少一部分业务，并将镜像部分通过镜像数据管道312引导至IoT设备事件检测引擎314。

IoT设备事件检测引擎314旨在表示检测由LAN 302上的IoT设备发送和/或接收的消息并将事件（或事件的表示）存储在IoT设备事件数据存储316中的引擎。在特定实现中，IoT设备事件检测引擎314或其一部分在与IoT设备网关304相同的物理设备上实现。替代地或附加地，IoT设备事件检测引擎314或其一部分可以由消费者直接购买的因特网服务提供商提供，并充当网络之间的管道。

在特定实现中，IoT设备事件检测引擎314起作用来检测与由IoT设备（或向IoT设备）传输的消息相关联的网络事件。例如，IoT设备事件检测引擎314可以检测由IoT设备（或向IoT设备）传输的一个或多个数据分组，所述分组后续可以用于生成与IoT设备相关联的活动数据结构，该活动数据结构进而用于确定IoT设备对于IoT设备的给定简档而言是否正表现适当。

在特定实现中，IoT设备事件检测引擎314从协议数据单元（PDU）（诸如帧、分组、分段和/或数据报）生成事件参数，同时抑制存储PDU。具体而言，IoT设备事件检测引擎314可以从传输到IoT设备和从IoT设备传输的PDU生成事件元数据，而不将实际的PDU本地存储在非易失性存储装置中。（这不应当被解释为意味着IoT设备事件数据存储316根据事实本身被实现为非易失性存储装置）。

IoT设备事件数据存储316旨在表示检测到的事件或代表检测到的事件的数据的数据存储。在特定实现中，IoT设备事件数据存储316包括事件缓冲区。事件缓冲区包括保持一段时间的事件和特征的集合。事件缓冲区可以特定于与IoT设备相关联的简档。例如，事件缓冲区可以与特定设备类型的IoT设备相关联。可替代地或附加地，事件缓冲区可以特定于作为设备传感器事件、会话事件、应用事件、用户事件、协议事件和状态事件之一或其组合的事件。存储事件的方式可以或可以不取决于模式的性质，所述模式稍后将出于确定可接受或不可接受的IoT设备行为的目的被应用于事件。在特定实现中，模式包括符号（即，物理层PDU）。替代地或附加地，模式可以包括可与帧、分组或分段/数据报或其组件匹配的元素。在一些实现中，模式也可以匹配到会话、表示和/或应用层协议或组件。

IoT设备事件到活动生成引擎318旨在表示起作用来从IoT设备事件数据存储316中表示的事件中标识活动以用于存储在IoT设备活动数据存储320中的引擎。在特定实现中，IoT设备事件到活动生成引擎318确定作为活动的一部分而包括的设备传感器事件、会话事件、应用事件、用户事件、协议事件和状态事件中的一个或其组合。设备传感器事件可以包括发生在开放式系统互连（下文称为“OSI”）模型的物理层或数据链路层中的物理层处的事件。例如，设备传感器事件可以包括IoT设备用来与特定数据源通信的虚拟LAN（下文称为“VLAN”）。会话事件可以包括发生在OSI模型的网络层或传输层处的事件。例如，会话事件可以包括IoT设备用来与源通信的特定网络类型。应用事件包括发生在OSI模型的会话层、表示层和应用层中的一个或其组合处的事件。例如，应用事件可以包括在接入网络服务中在IoT设备处执行的应用的标识。设备事件可以包括发生在特定设备处的事件。用户事件可以包括关联于与IoT设备交互的特定用户而发生的事件。例如，用户事件可以包括其中特定用户与IoT设备交互的特定实例。状态事件可以包括与IoT设备是否正在操作相关联的事件。例如，状态事件可以包括指示IoT设备是否正在给定的操作效率范围内操作的事件。

在特定实现中，IoT设备事件到活动生成引擎318通过分析数据分组来标识活动参数（数据或元数据）。例如，如果数据分组可以与特定应用关联，则IoT设备事件到活动生成引擎318可以标识与IoT设备相关联地执行的特定应用的活动参数。IoT设备事件到活动生成引擎318可以使用分组报头分析来从传输到IoT设备或从IoT设备传输的数据分组中标识活动参数。可替代地或附加地，IoT设备事件到活动生成引擎318可以使用深度分组检查来从数据分组中标识活动参数。例如，IoT设备事件到活动生成引擎318可以使用深度分组检查来分析从IoT设备发送的数据分组的有效负载，并后续从数据分组中标识活动参数。作为另一个示例，IoT设备事件到活动生成引擎318可以将由IoT设备传输（或传输到IoT设备）的数据分组中的一个或多个与正在IoT设备上执行的特定应用的活动关联。

在特定实现中，IoT设备事件到活动生成引擎318起作用来使用基于简档的聚合来限定事件。事件可以与特定简档相关联，诸如为被剖析为X-光机器的IoT设备发送X-光图像。例如，IoT设备事件到活动生成引擎318可以基于从给定简档的IoT设备传输的数据分组的接收者来限定事件。作为另一个示例，如果IoT设备每晚与远程设备交换数据（离散事件），则离散事件可以被聚合。作为另一个示例，IoT设备事件到活动生成引擎318可以基于IoT设备ID或所使用的向给定简档的IoT设备或从给定简档的IoT设备传输数据分组的端口来聚合事件。作为另一个示例，IoT设备事件到活动生成引擎318可以基于事件是否是设备传感器事件、会话事件、应用事件、用户事件、协议事件和状态事件中的一个或其组合来聚合事件。有利的是，基于远程、每个应用、每个IP或其他因素的限定可以处于粒度级别上。

上下文数据存储320旨在表示IoT网络相关数据的数据存储，其帮助IoT设备事件到活动生成引擎318定性评估IoT设备事件数据存储316中表示的IoT设备事件。

IoT设备活动数据存储322旨在表示由IoT设备事件到活动生成引擎318参考上下文数据存储320已经从来自IoT设备事件数据存储316的限定的（例如，聚合、充实或以其他方式限定和变换）事件或代表事件的数据导出的活动数据结构的数据存储。如本文章中所使用的，活动是经标记的一个或多个事件的集合。 在活动包括一个且仅一个事件的情况下，该活动可以被称为离散事件。在活动包含多于一个事件的情况下，该活动可以称为复合事件。可以注意到，并非所有聚合事件都是活动，因为根据定义，活动是经标记的事件的集合；然而，如果聚合事件稍后被标记，则未标记的聚合事件可以成为活动。

IoT设备简档数据存储324旨在表示IoT设备的简档模板和/或LAN 302上的IoT设备的简档的数据存储。如本文章中所使用的，LAN 302上的每个IoT设备被假定为具有现存于IoT设备简档数据存储324中或尚未标识的简档。至少在概念上，针对其还未标识更精确简档的IoT设备可以具有“默认”简档、临时简档或“最佳猜测”简档。事实上，一些或者甚至所有IoT设备简档可以被视为“最佳猜测”简档，因为没有理由假设IoT设备对于最初被剖析、变得被感染或在某个点开始表现不稳定而言不会棘手。IoT设备事件到活动生成引擎318将取决于与事件相关联的IoT设备的简档来不同地处理事件。具体而言，不同的设备简档可以与不同的聚合、来自设备历史的充实数据的不同优先级、关于分组计数的最有用的标准化（仅举几例）相关联。

再次参考IoT设备事件到活动生成引擎318，在特定实现中，IoT设备事件到活动生成引擎318起作用来从IoT设备事件数据存储316中的事件生成分析特征。分析特征是包括复合事件的一个或多个加时间戳的事件的变换。如本文章中所使用的，复合事件包括多个事件参数，但被称为“事件”，这是更通用的术语，旨在表示离散事件或事件参数的组合（其可以包括一个或多个离散事件）。例如，离散事件（诸如从与离散温度感测实例相关联的温度计传输的信号）可以与信号目的地的事件参数、历史信号传输和类似分类的IoT设备的传输等相组合，以生成复合事件。在特定实现中，IoT设备事件到活动生成引擎318使用传输到LAN 302上的IoT设备或从该IoT设备传输的消息来生成IoT设备的分析特征。例如，IoT设备事件到活动生成引擎318可以检查传输到IoT设备的消息，以确定后续可以被加时间戳以创建IoT设备的分析特征的事件。在特定实现中，IoT设备事件到活动生成引擎318在数据汇总窗口（或时间窗口）内生成IoT设备的分析特征。例如，IoT设备事件到活动生成引擎318可以检查在一个小时的时段内从IoT设备传输的所有消息，以确定IoT设备的特征。作为另一个示例，IoT设备事件到活动生成引擎318可以检查在24小时的时段内从第一IoT设备传输的分组，并且检查在五分钟的时段内从第二IoT设备传输的分组，以提取第一和第二IoT设备的特征。IoT设备事件到活动生成引擎318用来提取IoT设备的特征的数据汇总窗口可以取决于IoT设备简档而变化。例如，IoT设备事件到活动生成引擎318可以取决于IoT设备是温度计还是X-光机器来变化用于提取操作中的IoT设备的特征的数据汇总窗口。

图4描绘了包括本地化代理的IoT设备活动生成系统的示例的示图400。示图400包括LAN 402、IoT设备404-1至IoT设备404-n（统称为IoT设备404）、IoT设备事件检测引擎406、IoT设备事件数据存储408、IoT设备事件到活动生成引擎410、IoT设备网关412和WAN414。图400中图示的组件可以包括在图3的示例中以相同名称描述的组件的一些功能性。

为了说明的目的，LAN 402被描绘为不同于通常将被认为是在LAN 402“上”的设备。IoT设备404旨在充当在LAN 402“上”的设备的示例。LAN 402和IoT设备404可以被表征为IoT LAN。

IoT设备事件检测引擎406旨在表示也在LAN 402上的一个或多个代理。本地代理可以包括在LAN 402上的物理设备上实现的软件。在特定实现中，IoT设备事件检测引擎406的至少一部分通过IoT设备404、一个或多个专用IoT设备事件检测设备、IoT设备网关412或一些其他设备中的一个或多个上的一个或多个本地代理来实现；智能可以是分布式的。本地耦合涉及经由LAN接口（或更小的网络接口，诸如PAN接口）将本地代理操作性地连接到IoT设备404。在分布式企业网络中，本地代理可以在每个LAN处是本地的（在IEEE 802.11用语中，每个LAN有时被称为基本服务集（BSS），尽管这里没有暗示明确的要求），或者使用例如VLAN隧道本地化（在IEEE 802.11用语中，连接的LAN有时被称为扩展服务集（ESS），尽管这里没有暗示明确的要求）。取决于特定于实现的考虑或其他考虑，IoT设备事件检测引擎406可以包括有线通信接口和无线通信接口，用于通过有线或无线通信信道进行通信。

替代地或附加地，IoT设备事件检测引擎406的至少一部分可以相对于IoT设备404远程实现。例如，IoT设备事件检测引擎406的至少一部分可以在基于云的系统中实现。在该示例中，相对于IoT设备404远程实现的IoT设备事件检测引擎406的部分可以通过虚拟专用网络（下文称为“VPN”）隧道接收与IoT设备404相关联的数据。例如，IoT设备事件检测引擎406可以通过VPN隧道接收从IoT设备404发送的出站网络业务。另外，IoT设备事件检测引擎406可以通过其发送和接收数据的VPN隧道可以使用专用联网装备来维护。例如，IoT设备事件检测引擎406可以使用用于与IoT设备404通信的专用路由器来接收与IoT设备404相关联的数据。

在操作中，IoT设备事件检测引擎406将IoT设备事件保存在IoT设备事件数据存储408中，以供IoT设备事件到活动生成引擎410使用。在特定实现中，IoT设备事件到活动生成引擎410的至少一部分通过IoT设备404、一个或多个专用IoT设备事件检测设备、IoT设备网关412或一些其他设备中的一个或多个上的一个或多个本地代理来实现；智能可以是分布式的。

IoT设备网关412为从IoT设备404到WAN 414的IoT设备消息的子集提供出口，并为从WAN 414去往IoT设备的IoT设备消息提供入口。IoT设备网关412可以或可以不（例如，从非IoT设备消息）获得并提供附加数据，如果适用的话，其可以被提供给IoT设备事件到活动生成引擎410。

图5描绘了IoT设备活动抽取系统的示例的示图500。这样的系统可以并入IoT设备活动生成系统。参见例如图3的IoT设备事件到活动生成引擎318、图4的IoT设备事件到活动生成引擎410、或者更一般地图1的IoT设备活动生成引擎106。图500包括原始数据数据存储502、领域知识数据存储504、IoT设备事件限定引擎506、IoT设备活动类数据存储508、IoT设备活动抽取引擎510和IoT设备活动实例数据存储512。

原始数据数据存储502旨在表示本文章中先前描述的数据存储的集合，包括IoT设备事件、上下文、IoT设备简档等的数据存储。例如，上下文和IoT设备简档与领域知识之间可能存在某种交叉，但是对于理解图5而言，进行明确的区分并非必要。

领域知识数据存储504旨在表示已经根据外部源、管理输入或机器学习结果等设计的规则和模板。例如，通过模板化复合登录事件使得登录相关事件可以与其他预期的登录事件聚合以企图符合领域知识复合登录事件模板，领域知识使能实现更复杂的事件限定。

IoT设备事件限定引擎506旨在表示使用来自领域知识数据存储504的规则和/或模板来标识来自原始数据存储502的原始数据（包括至少一个事件）的相关性以及所述原始数据之间的相关性的引擎。“限定”旨在意味着对原始数据（并且特别是以及事件）的任何表征，使得原始数据的抽取呈现改进的预测能力。照此，限定可以包括聚合、充实和变换。（应当注意的是，“量化”也可能适用，并且如果不通过上下文或明确地加以区分，则如果适当的话应当将其视为限定的一部分。）

在示图500中，IoT设备事件限定引擎506包括IoT设备事件聚合引擎514、IoT设备事件充实引擎516和IoT设备事件变换引擎518。IoT设备事件聚合引擎514旨在表示对事件进行聚合的引擎。在平凡的示例中，持久网络会话可以被分成多个间隔（事件），所述间隔可以被聚合以形成包括持久网络会话的每个间隔的复合事件。IoT设备活动抽取引擎510可以将复合事件视为单个活动数据结构参数（假设复合事件没有例如通过与其他事件的聚合而甚至被进一步抽取）。在特定实现中，IoT设备事件聚合引擎514按IoT设备简档类型进行聚合。有利的是，按简档类型聚合可以使大量数据可管理。可替代地或附加地，IoT设备事件聚合引擎514根据领域知识数据存储504中的聚合规则，按源、目的地、用户、持续时间、一天中的时间和应用（仅举几个选项）中的一个或多个来聚合事件。可替代地或附加地，IoT设备事件聚合引擎514使用领域知识数据存储504中的复合事件模板来聚合与复合事件模板的组件的特性相匹配的离散事件。

IoT设备充实引擎516旨在表示将数据附加到事件的引擎。例如，IoT设备充实引擎516可以将IoT设备历史或IoT设备信息附加到以IoT设备为源的网络事件，以形成复合事件。IoT设备活动抽取引擎510可以将复合事件视为单个活动数据结构参数，但是例如具有更大的置信度。可以附加的其他数据可以包括例如检测到事件时的网络状况、与IoT设备相关联的账户的用户信息、以及与应用或设备的功能相关联的勘误表，仅举几例。

IoT设备事件变换引擎518旨在表示将来自原始数据存储502的事件及其相关联的数据转换成适于并入活动数据结构的格式的引擎。例如，转化可以包括将事件的字节计数分类为四个类别（例如，0-100KB、100KB-10MB、10MB-1GB和1GB以上）。IoT设备活动抽取引擎510可以类似地处理相同类别的事件，而不考虑已经被确定为比有用的更精确的精准字节计数。其他转化可以包括例如将IP转化成URL，通过分组计数标准化到通用标度，以及将MAC地址的组织唯一标识符（OUI）转换成制造商，仅举几例。

IoT设备活动类数据存储508旨在表示一个或多个活动数据结构模板的数据存储。在面向对象编程上下文中，模板可以被定义为用于创建活动数据结构实例的可扩展程序代码模板（例如，对象）。如本文章中所使用的，术语“类”旨在被解释得更广泛一点，除非明确指示使用了面向对象的方法，或者上下文指示多。

IoT设备活动抽取引擎510旨在表示一引擎，该引擎从IoT设备活动类数据存储508创建活动数据结构的实例，将从来自IoT设备事件限定引擎506的一个或多个限定合成事件抽取的值应用于实例化活动数据结构的参数，并为IoT设备活动实例数据存储512创建新的IoT设备活动数据结构实例。在特定实现中，IoT设备活动抽取引擎510还可以由抽取处理的结果应得的那样，更新IoT设备活动实例数据存储512、从其中读取或从其中删除。

有利的是，尽管当从原始数据（在特定实现中预期为大量的原始数据）实例化抽取（在特定实现中预期为大量的抽取）时数据必然“丢失”，但是IoT设备活动抽取引擎510可以维护到适用的原始数据的指针，如图5的示例中由从IoT设备活动实例数据存储512到原始数据数据存储502的指针箭头520所表示的。以此方式，IoT设备活动抽取引擎510可以被表征为利用指针替换原始数据。可替代地或附加地，原始数据可以利用简化的描述符或以某种其他适用的方式来替换。

图6描绘了IoT设备活动模式匹配系统的示例的示图600。示图600包括IoT设备活动预测引擎602、耦合到IoT设备活动预测引擎602的IoT设备活动实例数据存储604、耦合到IoT设备活动预测引擎602的简档特定的活动模式数据存储606、耦合到IoT设备活动预测引擎602的正常活动数据存储608、耦合到IoT设备活动预测引擎602的可疑活动数据存储610、耦合到正常活动数据存储608和可疑活动数据存储610的基于场景的验证引擎612、领域知识导出规则数据存储614、经验证活动数据存储616、耦合到可疑活动数据存储610的抽取引擎618、耦合到抽取引擎618的上下文数据存储620、耦合到抽取引擎618的风险抽取数据存储622、耦合到经验证活动数据存储616和风险抽取数据存储622的漏洞检测引擎624、耦合到上下文数据存储620和风险抽取数据存储622的严重性确定过滤引擎626、以及耦合到严重性确定过滤引擎626的原始数据数据存储628。

IoT设备活动预测引擎602旨在表示采用为多个活动构建的活动模型并尝试将检测到的活动与适用于给定IoT设备简档的活动模型相匹配的引擎。有利的是，IoT设备活动预测引擎602可以将活动与活动模式相匹配，不仅用于检测恶意软件，而且（或者也）用于基于与活动相关联的IoT设备的简档来检测正常活动；签名可以匹配正常行为。在特定实现中，模式在活动级别匹配，如与事件级别相对的那样。

IoT设备活动实例数据存储604旨在表示包括网络事件的多个活动数据结构，所述网络事件已经被聚合、充实和/或与其他事件关联以定义检测到的活动。在特定实现中，活动数据结构可以使用包括活动类的语言、定义活动数据格式和过程来形成。在这样的实现中，活动数据结构可以被表征为活动类的实例（即，活动对象），它可以响应于事件的变换来修改其属性，并且包含表示包括活动的事件的一组事件类的实例（即，事件对象）。

简档特定的活动模式数据存储606旨在表示适用于特定简档的活动模式数据存储（未示出）的子集。出于说明的目的，假设简档特定的活动模式数据存储606包括各种不同活动的模式。

正常活动数据存储608旨在表示（至少在当下）已被认为是良性的活动数据结构的数据存储。IoT设备活动预测引擎602可以包括置信度阈值，该置信度阈值关于活动是否被放入正常活动数据存储608中是确定性的（尽管在特定实现中是可配置的）。因此，正常活动可以具有相关联的置信度值。例如，可以使用正常活动来改进机器学习模型。

可疑活动数据存储610旨在表示已被认为是潜在恶意的或以其他方式不合期望的活动数据结构的数据存储。

基于场景的验证引擎612旨在表示考虑正常活动数据存储608中的活动在鉴于附加数据考虑时是否实际可疑的引擎。在正常活动数据存储608中的活动数据结构具有置信度值的实现中，置信度值可随时间的推移而调整，并且如果置信度值超过置信度阈值，则（多个）相关的活动数据结构被替代地移动到可疑活动数据存储610。

领域知识导出规则数据存储614旨在表示包括规则的数据存储，所述规则适用于关于先前已被指定为良性的活动数据结构是否应当被指定为可疑的确定。例如，如果被单独考虑的多个活动是良性的，但是当被聚合地考虑时是可疑的，则当IoT设备活动预测引擎602考虑第二活动数据结构时，正常活动数据存储608中的第一活动数据结构可能遭受降低的置信度。也就是说，组合地考虑的多个“正常”活动可能是可疑的。这就是基于场景的验证引擎612被称为“基于场景”的原因。具体而言，在特定场景下，良性活动可以被重新表征为可疑活动。

经验证活动数据存储616旨在表示包括已经由基于场景的验证引擎612验证的活动数据结构的数据存储。出于说明的目的，假设这样的数据结构具有不改变的“经验证”状态，但是应当理解，在实践中，经验证活动可以具有随时间的推移而变化的置信度阈值，这可能导致经验证活动数据结构被降级为可疑（或回到正常）。当基于场景的验证引擎612未能验证活动时，基于场景的验证引擎612可以将对应的活动数据结构存储在可疑活动数据存储610中（如前所述），而不是经验证活动数据存储616中。

抽取引擎618旨在表示将活动抽取成行为的引擎，行为是一个或多个相关活动的应用驱动的集合。可替代地或附加地，抽取可以是到个性，个性是行为的集合。行为用于描述特定类型的IoT设备。行为是应用驱动的，因为抽取引擎618知道在其上运行的应用（如由示图600中抽取引擎618到上下文数据存储620的耦合所表示的，其中上下文包括应用区分数据），所述应用与适当的策略相适应，所述策略诸如服务质量、选择性访问、特殊封装机制和/或应用特定的路由，仅举几个选项。在特定实现中，应用感知是通过网络的交换和/或路由结构分布适当的策略，以使用适用的协议（例如，SDN）在相关装备端口、网络分支上让它们致动。可替代地或附加地，通过使用网络管理工具配置网络设备或单独登录到适用的网络设备中并配置该适用的网络设备来实现适当的策略。这与不知道哪些应用被不同地对待的策略形成对比。取决于特定于实现、配置和偏好的因素，应用感知可以从相对粗粒度的、诸如从使用TCP或UDP端口号（例如，TCP端口80，用于利用一组策略批量进行http捕捉业务）变化到在分组的有效负载上使用DPI（在该情况下，可以完成web应用、特定用户等之间的区分）。在特定实现中，事件并入具有需要的相对粒度的网络会话，但是在一些但不是全部情形下使用DPI（例如，出于活动验证目的作为主动测试来更好地确认置信度）。

上下文数据存储620旨在表示包括未在可疑活动数据存储610中表示的活动（或行为或个性）数据结构、在基于场景的验证引擎612尚未采用领域知识来标识可疑活动以供存储在可疑活动数据存储610中的程度上的领域知识的数据存储，并且以其他方式充当改进将活动抽取成IoT设备的行为（或个性）数据结构的数据的总括。

风险抽取数据存储622旨在表示由抽取引擎618存储在其中的行为（或个性）数据结构的数据存储。

漏洞检测引擎624旨在表示考虑来自经验证活动数据存储616的经验证活动数据结构和风险抽取数据存储622中的行为数据结构来标识IoT网络中的漏洞的引擎。在特定实现中，漏洞检测被用于改进用于机器学习的行为模型。可替代地或附加地，漏洞检测引擎624响应于漏洞检测修改经验证活动数据存储616。漏洞检测引擎624可以或可以不响应于漏洞检测而修改风险抽取数据存储622（尽管修改经验证活动数据存储616可能随着影响在系统中进行作用而导致改变）。

严重性确定过滤引擎626旨在表示生成上下文化IoT网络漏洞报告的引擎。严重性确定过滤引擎626耦合到上下文数据存储620，在特定实现中，上下文数据存储620包括报告偏好。报告偏好可以包括用于从报告中过滤数据的默认阈值、自定义阈值和上下文导出阈值。默认阈值可以根本不包括阈值，从而允许报告所有行为数据结构，或者包括分级阈值，其对某些行为的权重不同于其他行为。自定义阈值可以并入关于应当并入到报告中的风险量和/或要生成的报告类型的网络管理员偏好。上下文导出阈值可以包括基于上下文调整的阈值；例如，如果存在许多潜在风险，可以过滤低风险报告。

原始数据数据存储628旨在表示包括通过先前的抽取过程丢失的数据的数据存储。指针箭头630旨在表示到由抽取引擎618（以及可能由漏洞检测引擎624）抽取出的原始数据的指针的维护，尽管对于执行抽取的任何适用的引擎（为了避免混乱，未示出）可能图示了类似的箭头。在特定实现中，严重性确定过滤引擎626在上下文化IoT网络漏洞报告中包括对在先前抽取过程期间使用适用的原始数据项位置标识符（诸如指针或简化描述符）过滤掉的原始数据的引用。有利的是，在该特定实现中，如果期望关于IoT设备行为（或多个IoT设备行为）的更精确，则网络管理员、或其人类或人工代理、或某个其他方可以深入到上下文化的IoT网络漏洞报告中。

图7描绘了IoT设备剖析系统的示例的图700。图700包括IoT设备个性定义引擎702、耦合到IoT设备个性定义引擎702的IoT设备活动实例数据存储704、耦合到IoT设备个性定义引擎702的领域知识数据存储706、耦合到IoT设备个性定义引擎702的IoT设备简档数据存储708、耦合到IoT设备个性定义引擎702和IoT设备简档数据存储708的离线建模引擎710，耦合到IoT设备个性定义引擎702和IoT设备简档数据存储708的个性分类引擎712、耦合到个性分类引擎712的判定生成引擎、耦合到IoT设备简档数据存储708和判定生成引擎714的IoT设备剖析引擎716、以及耦合到领域知识数据存储706和判定生成引擎714的网络管理引擎718。

IoT设备个性定义引擎702旨在表示使用来自IoT设备活动实例数据存储704的与IoT设备相关联的活动和来自领域知识数据存储706的领域知识来定义IoT设备的个性的引擎。在特定实现中，IoT设备个性定义引擎702通过在IoT设备简档数据存储708中创建、读取、更新和/或删除（粗略化）IoT设备简档数据结构来促进IoT设备的剖析。可替代地或附加地，IoT个性定义引擎702可以通过定义指示IoT设备的行为的特征值，使用聚合的、充实的和/或变换的事件（活动数据结构）来定义IoT设备的个性。

离线建模引擎710旨在表示使用从IoT个性定义引擎702提供的特征值来构建用于IoT网络安全中使用的行为检测模型的引擎。在特定实现中，离线建模引擎710使用指示IoT设备行为的特征值来构建基于上下文的不期望行为检测模型。替代地或附加地，离线建模引擎710可以使用适用的机器学习引擎来识别特征值中的行为模式，并构建基于上下文的不期望行为检测模型。例如，离线建模引擎710可以使用基于学习状态转变的学习（包括基于决策树的分类、基于神经网络的分类或其他适用的机器学习分类）和深度学习中的一个或这两者来标识IoT设备的行为模式。在特定实现中，离线建模引擎710向IoT设备简档数据存储708提供模型。

个性分类引擎712旨在表示将行为检测模型应用于从IoT个性定义引擎702提供的特征值的引擎。在特定实现中，个性分类引擎712将IoT设备简档数据存储708中基于上下文的不期望行为检测模型（来自离线建模引擎710）应用于由IoT个性定义引擎702标识的IoT设备的特征值。在这样的实现中，个性分类引擎712可以生成将IoT设备的检测到的行为（从IoT设备活动实例数据存储704导出）与IoT设备的建模行为进行比较的信号。

判定生成引擎714旨在表示使用来自个性分类引擎712的信号来生成判定的引擎。

IoT设备剖析引擎716旨在表示标识IoT设备的个性简档的引擎。IoT设备剖析引擎716可以基于从IoT设备活动实例数据存储704中的活动数据结构导出的实际行为和由IoT设备个性定义引擎702确定的特征值（在概念上，特征值被假设为从IoT设备个性定义引擎702传递到个性分类引擎716，个性分类引擎716可以将特征值传递到IoT设备剖析引擎716或者提供某种其他抽取，诸如行为或个性），来检测针对IoT设备的IoT设备简档数据存储708中是否存在IoT设备简档。在特定实现中，IoT设备剖析引擎716利用个性数据集来更新IoT设备简档数据存储708，IoT个性定义引擎702可以使用该个性数据集来改进其特征值生成功能。

在特定实现中，判定生成引擎714生成指示IoT设备如何偏离正常行为模式（例如，良性行为模式）的警报，该警报被提供给网络管理引擎716。网络管理引擎716旨在表示根据行为警报更新领域知识数据库706的引擎。在特定实现中，该警报是不期望的行为警报。

可以按照情况需求对在先的文本和各图中描述的技术进行混合和匹配，以产生替代实现。