Multi-dimensional periodic detection of IoT device behavior

Abstract

The present application relates to a technique for detecting abnormal behavior of an Internet of Things (IoT) device in an IoT network. IoT events of the IoT device are captured and analyzed to identify periodic activity of the IoT device. Periodic activity of the IoT device is tracked over time, and changes in the periodic activity are analyzed to assess potential threats to the IoT network.

Description

Technical Field

[0001] This application is a divisional application of Application No.: 201980066292.X Invention Name: Multidimensional Periodic Detection of IoT Device Behavior. This application relates to multidimensional periodic detection of IoT device behavior. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 A diagram depicting an example of an Internet of Things (IoT) cybersecurity system.

[0003] Figure 2 A diagram depicting an example of an on-prem IoT controller.

[0004] Figure 3 A diagram depicting an example of an off-prem IoT application controller.

[0005] Figure 4 A diagram depicting an example of a hybrid IoT controller utilizing a service-oriented architecture (SOA) is depicted.

[0006] Figure 5 A diagram depicting an example of an IoT signal signature generation engine.

[0007] Figure 6 A diagram depicts an example of a periodic activity definition engine.

[0008] Figure 7 A graph illustrating event detection over time is depicted.

[0009] Figure 8 A flow chart depicting an example of a method for IoT periodic activity learning. DETAILED DESCRIPTION

[0010] Figure 1A diagram 100 of an example of an Internet of Things (IoT) cybersecurity system is depicted. The diagram 100 includes a computer readable medium (CRM) 102, IoT devices 104-1 ... 104-n (collectively "IoT devices 104") coupled to the CRM 102, an IoT controller engine 106 coupled to the CRM 102, an event capture engine 108 coupled to the CRM 102, an event datastore 110 coupled to the CRM 102, an IoT signal feature generation engine 112 coupled to the CRM 102, an IoT signal feature datastore 114 coupled to the CRM 102, a periodic activity generation engine 116 coupled to the CRM 102, an activity datastore 118 coupled to the CRM 102, an abnormal periodic activity IoT network threat assessment engine 120 coupled to the CRM 102, and an alarm datastore 122 coupled to the CRM 102.

[0011] The CRM 102 and other computer-readable media discussed herein are intended to represent a wide variety of potentially applicable technologies. For example, the CRM 102 may be used to form a network or a portion of a network. In the case where two components are co-located on a device, the CRM 102 may include a bus or other data conduit or plane. In the case where a first component is located on one device and a second component is located on a different device, the CRM 102 may include a wireless or wired backend network or LAN. If applicable, the CRM 102 may also cover relevant portions of a WAN or other network.

[0012] Computer-readable media discussed herein are intended to include all legal media (e.g., in the United States, pursuant to 35 USC 101), and all media that are not legal in nature are specifically excluded to the extent that they are excluded as necessary for a claim including computer-readable media to be effective. Known legal computer-readable media include hardware (e.g., registers, random access memory (RAM), non-volatile (NV) storage devices, to name a few), but may or may not be limited to hardware.

[0013] The device, system and computer readable medium described herein can be implemented as a computer system, or a part of a computer system, or a plurality of computer systems. In general, a computer system will include a processor, a memory, a non-volatile storage device and an interface. A typical computer system will usually include at least a processor, a memory and a device (e.g., a bus) by which the memory is coupled to the processor. The processor can be, for example, a general-purpose central processing unit (CPU) (such as a microprocessor) or a special-purpose processor (such as a microcontroller).

[0014] The memory may include, by way of example and not limitation, random access memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). The memory may be local, remote, or distributed. The bus may also couple the processor to a non-volatile storage device. The non-volatile storage device is often a magnetic floppy or hard disk, a magneto-optical disk, an optical disk, a read-only memory (ROM) (such as a CD-ROM, EPROM, or EEPROM), a magnetic or optical card, or another form of storage device for large amounts of data. During the execution of software on the computer system, some of this data is often written to the memory through a direct memory access process. The non-volatile storage device may be local, remote, or distributed. The non-volatile storage device is optional because the system can be created with all applicable data in the memory.

[0015] Software is usually stored in a non-volatile storage device. In fact, for large programs, it may even be impossible to store the entire program in a memory. Nevertheless, it should be understood that, in order for the software to run, it is moved to a computer-readable position suitable for processing, and for illustrative purposes, the position is referred to as a memory in this article. Even when the software is moved to the memory for execution, the processor will also utilize hardware registers to store the values ​​associated with the software, and the local high-speed cache used to speed up execution in the ideal case. As used in this article, when a software program is referred to as "implemented in a computer-readable storage medium", it is assumed that the software program is stored in a known or convenient location (from a non-volatile storage device to a hardware register) that is applicable. When at least one value associated with a program is stored in a processor-readable register, the processor is considered to be "configured to execute a program".

[0016] In one example of operation, a computer system may be controlled by operating system software, which is a software program that includes a file management system, such as a disk operating system. An example of operating system software with associated file management system software is the Windows family of operating systems, known as the Windows XP family from Microsoft Corporation of Redmond, Washington. and their associated file management systems. Another example of operating system software and its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in a non-volatile storage device and causes the processor to perform various actions required by the operating system to input and output data and store data in memory, including storing files on the non-volatile storage device.

[0017] The bus can also couple the processor to the interface. The interface can include one or more input and / or output (I / O) devices. Depending on the specific or other considerations of the implementation, the I / O device can include (as an example and not limitation) a keyboard, a mouse or other pointing device, a disk drive, a printer, a scanner and other I / O devices, including a display device. As an example and not limitation, the display device can include a cathode ray tube (CRT), a liquid crystal display (LCD) or some other applicable known or convenient display device. The interface can include one or more of a modem or a network interface. It will be appreciated that a modem or a network interface can be considered as a part of a computer system. The interface can include an analog modem, an ISDN modem, a cable modem, a token ring interface, a satellite transmission interface (e.g., "direct PC") or other interfaces for coupling a computer system to other computer systems. The interface enables a computer system and other devices to be coupled together in a network.

[0018] The computer system may be compatible with a cloud-based computing system, or implemented as part of a cloud-based computing system, or implemented by a cloud-based computing system. As used herein, a cloud-based computing system is a system that provides virtualized computing resources, software, and / or information to end-user devices. Computing resources, software, and / or information may be virtualized by maintaining centralized services and resources that edge devices can access through communication interfaces such as networks. "Cloud" may be a marketing term, and for the purposes of this article, it may include any network described herein. A cloud-based computing system may involve a service subscription or use a utility pricing model. A user may access the protocol of a cloud-based computing system through a web browser or other container application located on their end-user device.

[0019] The computer system can be implemented as an engine, as a part of an engine, or by multiple engines. As used herein, an engine includes one or more processors or a part thereof. A part of one or more processors may include a portion of hardware less than all the hardware including any given one or more processors, such as a subset of registers, a portion of the processor dedicated to one or more threads of a multithreaded processor, a time slice, during which the processor is dedicated in whole or in part to a portion of the function of the execution engine, and the like. As such, the first engine and the second engine may have one or more dedicated processors, or the first engine and the second engine may share one or more processors with each other or other engines. Depending on implementation-specific or other considerations, the engine may be centralized or its function may be distributed. The engine may include hardware, firmware, or software embodied in a computer-readable medium for execution by a processor. The processor converts data into new data using implemented data structures and methods, such as described with reference to the various figures herein.

[0020] The engine described herein or the engine by which the systems and devices described herein may be implemented may be a cloud-based engine. As used herein, a cloud-based engine is an engine that can use a cloud-based computing system to run applications and / or functions. All or part of the applications and / or functions can be distributed across multiple computing devices, without being limited to only one computing device. In some embodiments, a cloud-based engine can execute functions and / or modules that an end user accesses through a web browser or container application without having to install the functions and / or modules locally on the end user's computing device.

[0021] As used herein, a data store is intended to include a repository having any applicable data organization, including tables, comma-separated value (CSV) files, traditional databases (e.g., SQL), or other applicable known or convenient organizational formats. The data store may be implemented, for example, as software embodied in a physical computer-readable medium on a dedicated machine, in firmware, in hardware, a combination thereof, or in an applicable known or convenient device or system. Components associated with the data store (such as a database interface) may be considered "part" of the data store, part of some other system component, or a combination thereof, although the physical location and other characteristics of the components associated with the data store are not critical to understanding the techniques described herein.

[0022] Data storage may include data structures. As used herein, a data structure is associated with a specific way of storing and organizing data in a computer so that it can be used efficiently in a given context. Data structures are generally based on the ability of a computer to obtain and store data anywhere in its memory, which is specified by an address, and the bit string itself can be stored in the memory and manipulated by the program. Therefore, some data structures are based on calculating the addresses of data items using arithmetic operations; while other data structures are based on storing the addresses of data items inside the structure itself. Many data structures use these two principles, sometimes combined in a non-trivial way. The implementation of a data structure generally requires writing a set of procedures that create and manipulate instances of the structure. The data storage described herein may be a cloud-based data storage. A cloud-based data storage is a data storage compatible with a cloud-based computing system and engine.

[0023] return Figure 1 In an intentionally constructed IoT device, IoT device 104 is intended to represent an IoT device that is purposefully constructed or configured. Examples of IoT devices include: thermostats, mobile devices, bio-managers, sensory devices, and function-implementing devices. In an intentionally constructed IoT device, IoT device 104 is constructed to have specific operating parameters. For example, a thermometer may be constructed to provide a signal from a temperature sensor. In an intentionally configured IoT device, IoT device 104 may be configured to operate according to specific operating parameters based on input from a person or artificial agent. For example, an IoT device in IoT device 104 may be a thermostat that is configured to control an air conditioner to cool a room to a configurable temperature at a configurable time. Other examples include: infusion pumps, imaging devices (e.g., CT scanners, X-ray machines, picture archiving and communication systems (PACS), and digital imaging and communications in medicine ( ) workstation). As another example, the agent can specify that the IoT device should not communicate with a specific data source, but should only be used to view DICOM images, and can configure the IoT device to refrain from communicating with a specific data source, or perform actions other than viewing DICOM images, as part of an intentional configuration. In order for an intentionally configured device to be considered an IoT device, it should operate within IoT operating parameters; if deviations can be determined, deviations from IoT operating parameters can result in elevated risk and / or triggering alerts, such as "browser usage."

[0024] In a particular implementation, the IoT device 104 includes: a wired or wireless interface through which the IoT device 104 can send and receive data through wired and wireless connections. As used herein, the term "implementation" means an implementation used to illustrate by way of example and not necessarily by way of limitation. The IoT device 104 may have a unique identifier that can be used in data transmission over a network. The unique identifier of the IoT device 104 may include an identifier created in accordance with Internet Protocol version 4 (hereinafter referred to as "IPv4"), or an identifier created in accordance with Internet Protocol version 6 (hereinafter referred to as "IPv6"), both of which are hereby incorporated by reference. Depending on implementation-specific or other considerations, the IoT device 104 may include an applicable communication interface for receiving and sending data in accordance with an applicable wireless device protocol. Examples of applicable wireless device protocols include Wi-Fi, and other applicable low power communication standards.

[0025] In a specific implementation, IoT device 104 acts as a station. As used herein, a station may be referred to as a device having a media access control (MAC) address and a physical layer (PHY) interface with a wireless medium, which complies with the IEEE 802.11 standard. Thus, for example, if applicable, a network device may be referred to as a station. IEEE 802.11a-1999, IEEE 802.11b-1999, IEEE 802.11g-2003, IEEE 802.11-2007, and IEEE 802.11n TGn Draft 8.0 (2009) are incorporated by reference. As used herein, an 802.11 standard-compatible or 802.11 standard-compliant system at least complies with the requirements and / or recommendations of the incorporated document, or some of the requirements and / or recommendations from an early draft of the document, and includes a Wi-Fi system. Wi-Fi is a non-technical description that is often associated with the IEEE 802.11 standard and the Wi-Fi Protected Access (WPA) and WPA2 security standards and the Extensible Authentication Protocol (EAP) standard. In alternative embodiments, a station may follow standards different from Wi-Fi or IEEE 802.11, may be referred to as something other than a "station," and may have a different interface with a wireless or other medium.

[0026] In a specific implementation, the IoT device 104 is configured to access network services that comply with IEEE 802.3. IEEE 802.3 is a collection of IEEE standards developed by a working group and the working group, which defines the physical layer and data link layer MAC of wired Ethernet. This is generally a local area network technology for some wide area network applications. Physical connections are typically established between nodes and / or infrastructure devices (hubs, switches, routers) through various types of copper or optical cables. IEEE 802.3 is a technology that supports the IEEE 802.1 network architecture. As is well known in the relevant art, IEEE 802.11 is a working group and collection of standards for implementing wireless local area network (WLAN) computer communications in 2.4, 3.6 and 5 GHz bands. The basic version of the standard IEEE 802.11-2007 has been subsequently revised. These standards provide the basis for wireless network products using the Wi-Fi trademark. IEEE 802.1 and 802.3 are incorporated by reference.

[0027] In a specific implementation, the IoT device 104 has a corresponding personality. As used herein, a personality is a collection of behaviors; behaviors are used to describe a specific type of device. As used herein, a behavior is an application-driven collection of one or more related activities. The personality can be bad, which means that the personality can be identified as a personality that belongs to a device that exhibits or has an unacceptable risk of exhibiting undesirable behavior later. The personality can be good, which means that the personality can be identified as a personality that belongs to a device that does not and is not expected to exhibit undesirable behavior later. Devices can exhibit abnormal behavior, and anomaly detection is a useful tool to determine whether a device exhibits undesirable behavior, so abnormal behavior is sometimes associated with undesirable behavior. However, over time, abnormal behavior may indicate a personality that has not yet been confirmed but is potentially good. If a device with a first personality exhibits abnormal behavior, it may be possible to define a second personality that is similar to the first personality in some respects, but for which a certain behavior is not abnormal. Similarly, over time, the first personality can be better defined to include behaviors that were previously abnormal behaviors as non-abnormal behaviors. Therefore, it may be desirable to provide a system that can not only classify IoT devices as having various personalities, but also provide a system that can allow personalities to have a malleable definition and new personalities to be defined over time.

[0028] The IoT controller engine 106 is intended to represent a system that provides services to one or more of the IoT devices 104. In a particular implementation, the "server portion" of an application runs on (or through) the IoT controller engine 106, which can be implemented as a cluster of virtual machines and / or application servers, and the "client portion" runs on one or more of the IoT devices 104. The "server portion" and "client portion" may be collectively referred to as an IoT application, and the IoT controller engine may be referred to as an IoT application controller engine (it may be noted that the "client portion" is sometimes conflated with the front end of a server, in which case the "client portion" may be characterized as the front end of a server, and the "server portion" may be characterized as the back end of a server; the context will dictate). In a particular implementation, the IoT controller engine 106 is "locally" located, an example of which is in Figure 2 is provided as an example.

[0029] The event capture engine 108 is intended to represent an engine capable of detecting events occurring on the CRM 102. The location of the sensor may determine the event capture function. For example, the event capture function may be detected by monitoring wireless packets sent between the IoT device 104 and the IoT controller 106, or by monitoring the communication between the load balancer and the front-end application engine (e.g., see Figure 3 ) to detect network events. Other examples include: listening on a message bus, capturing syslog messages, and so on. In a local implementation, the event capture engine 108 can be implemented using a mirror to enable, for example, packet sniffing, but in the cloud, the event capture engine 108 can use a message "bus", a packet forwarder (e.g., a script on a load balancer to forward packets), or log-based analysis. In a specific implementation, the event capture engine 108 is lightweight, which is desirable to give the ability to correlate events captured by multiple different inspectors at multiple different locations. Newly captured events can be characterized as "raw" events, and this characterization can continue until the event is normalized or otherwise abstracted in some way. The original event may or may not be maintained in the abstracted data store, depending on whether it is desirable to facilitate auditing, historical analysis, or otherwise utilize the original event data.

[0030] Understanding the structure of IoT application data and the payloads that applications carry in network transmissions is essential when modeling IoT device behavior. Existing IoT security solutions focus on leveraging network metadata for modeling, but are less effective when used in situations where more data protection is required, such as data leak prevention (DLP). The event capture engine 108 addresses these deficiencies by capturing network payloads in plain text (e.g., for local implementations) or in a format suitable for the desired deployment model (with normalization for different event formats, if applicable).

[0031] Figure 2 A diagram 200 of an example of a local IoT controller is depicted. The diagram 200 includes a LAN 202, an IoT device 204 coupled to the LAN 202, an IoT controller engine 206 coupled to the LAN 202, services 208-1 to 208-n (services 208) coupled to the IoT controller engine 206, a firewall 210 coupled to the LAN 202, and a WAN 212 coupled to the firewall 210. It may be noted that the IoT device 204, the IoT controller engine 206, the services 208, and the firewall 210 may also be referred to as being "on the LAN 202" or "locally".

[0032] LAN 202 is intended to represent a relatively local network of IoT devices, IoT controller engines, and possibly other devices. It should be noted that an enterprise network may include geographically distributed LANs coupled across WAN segments. In a distributed enterprise network, gateways may be local to each LAN (although not explicitly required here, in IEEE 802.11 parlance, each LAN is sometimes referred to as a Basic Service Set (BSS)) or localized using, for example, VLAN tunnels (although not explicitly required here, in IEEE 802.11 parlance, connected LANs are sometimes referred to as Extended Service Sets (ESS)), although some form of gateway functionality is typically still required to connect the various LANs in a geographically distributed enterprise network.

[0033] Can be used with reference Figure 1 IoT device 204 may be implemented in a manner similar to that described for IoT device 104. Figure 1The IoT controller engine 206 is implemented in a manner similar to that described for the IoT controller 106. Services 208 are intended to represent local services provided to the IoT devices 204 by the IoT controller engine 206. Firewall 210 is intended to represent an example of a device located between local devices of the LAN 202 (such as the IoT devices 204 and the IoT controller engine 206) and off-site devices of the WAN 212 (which typically includes other networks, including LANs, not shown).

[0034] In a particular implementation, the inspector is coupled to the LAN 202 at the location identified by arrow 214 (i.e., the inspector is "on the LAN 202" and may be referred to as a local inspector). In such an implementation, it would not be uncommon for network traffic to be transmitted in clear text between the IoT device 204 and the IoT controller engine 206. For example, the inspector may be implemented as a sniffer capable of detecting network traffic between the IoT device 204 and the IoT controller engine 206.

[0035] Reference again Figure 1 In a specific implementation, the IoT controller engine 106 and the event capture engine 108 are located "off-site", an example of which is shown in Figure 3 In addition, the event capture engine 108 may have a local component that, for example, monitors transmissions to or from IoT devices.

[0036] Figure 3 A diagram 300 of an example of an off-premises IoT application controller is depicted. The diagram 300 includes a LAN 302, an IoT device 304 coupled to the LAN 302, a firewall 306 coupled to the LAN 302, a WAN 308 coupled to the firewall 306, and an IoT application controller 310 coupled to the WAN 308. It may be noted that the IoT device 304 and the firewall 306 may also be referred to as being "on the LAN 302" or "locally," while the IoT application controller engine 310 may also be referred to as being "on the WAN 308" (rather than on the LAN 302) or "off-premises." In a particular implementation, the IoT application controller 310 is implemented in the cloud.

[0037] LAN 302 is intended to represent a relatively local network of IoT devices and other potential devices. Figure 1IoT device 304 is implemented in a manner similar to that described for IoT device 104. Firewall 306 is intended to represent an example of a device located between local devices on LAN 302 (such as IoT device 304) and off-site devices on WAN 308 (such as IoT application controller engine 310). The link between WAN 308 and IoT application controller engine 310 can be implemented via, for example, a virtual private network (VPN) engine (not shown) with a clear text protocol (a RESTful interface would be unlikely, but not necessarily inapplicable)).

[0038] Can be used with reference Figure 1 The IoT application controller engine 310 is implemented in a manner similar to that described for the IoT controller 106. In the diagram 300, the IoT application controller engine 306 includes: a load balancer 312, a front-end application engine 314 coupled to the load balancer 312, services 316-1 to 316-n (collectively referred to as services 316) coupled to the front-end application engine 314, and an API gateway 318 coupled to the load balancer 312 and the front-end application engine 314.

[0039] The load balancer 312 is intended to represent a server-side engine through which external clients can be coupled to a service. In a specific implementation, the load balancer 312 listens on a port to which external clients connect to access the service. The load balancer forwards the request to a backend server associated with the service. Advantageously, the load balancer 312 prevents the IoT device 304 from contacting the backend server directly. The load balancer 312 can be implemented to avoid making it a single point of failure, such as by implementing it as a high availability engine pair that can replicate session persistence data if desired for a given application.

[0040] Front-end application engine 314 is intended to represent the interface between load balancer 312 (client side) and service 316 (server side). Service 316 may be referred to as an off-site service, or in a specific implementation, may be referred to as an off-site application service.

[0041] In a particular implementation, service 316 represents a portion of a microservices architecture, where services are fine-grained and protocols are lightweight. A microservices-based architecture enables continuous delivery and deployment, and often includes: processes that communicate over a network to achieve a goal using a technology-agnostic protocol (such as HTTP) (but may include other kinds of inter-process communication mechanisms, such as shared memory); independently deployable services; easily replaceable services; services organized around functionality (e.g., user interface front end, recommendations, logistics, billing, etc.); services implemented using different programming languages, databases, hardware, and software environments depending on the most appropriate situation; and / or relatively small services that are messaging-enabled, context-constrained, autonomously developed, independently deployable, decentralized, and built and released using automated processes. Typically, microservices-based architectures naturally implement a distributed structure; are suitable for a continuous delivery software development process; follow principles such as fine-grained interfaces, business-driven deployment, cloud application architecture, polyglot programming and persistence, lightweight container development, decentralized continuous delivery, and DevOps with holistic service monitoring; and / or provide features that facilitate scalability.

[0042] The API gateway 318 is intended to represent the interface between the load balancer 312 and the service 316, but it acts as an API front end, receiving API requests. In a specific implementation, the API gateway 318 implements throttling and security policies, passes requests to the (backend) service 316, and passes responses to the IoT device 304. The API gateway 318 may or may not include a transformation engine to orchestrate and modify requests and responses on the fly, collect analytical data, provide caching, and support authentication, authorization, security, auditing, and regulatory compliance.

[0043] In a particular implementation, the event capture engine (which may be referred to as an off-site event capture engine or an off-site component of the event capture engine) is operably connected to the IoT application controller engine 310 at a location identified by arrow 320. In such an implementation, the checker is located "behind" the load balancer 312 (and may be referred to as an application load balancer checker), and the checker is located between the front-end application engine 314 and each of the services 316 (e.g., each of the services 316 has a checker in front of it, which may be referred to as an application service checker). Behind is intended to mean that the load balancer 312 is located between the checker and the IoT device 304.

[0044] Reference again Figure 1 In a specific implementation, the IoT controller engine 106 and the event capture engine 108 have two components, "local" and "off-site". Figure 4An example of this is provided as an example in .

[0045] Figure 4 A diagram 400 of an example of a hybrid IoT controller utilizing a service-oriented architecture (SOA) is depicted. As used herein, an SOA logically represents a business activity with a specified result, which is independent, a black box to a service requester, and can be composed of other basic services. Diagram 400 includes: a LAN 402, an IoT device 404 coupled to the LAN 402, an IoT controller engine 406 coupled to the LAN 402, services 408-1 to services 408-n (collectively referred to as services 408) coupled to the IoT controller engine 406, a firewall 410 coupled to the LAN 402, a WAN 412 coupled to the firewall 410, and an IoT application controller 414 coupled to the WAN 412. It can be noted that the IoT device 404, the IoT controller engine 406, and the firewall 410 can also be referred to as "on the LAN 402" or "local", while the IoT application controller engine 414 can also be referred to as "on the WAN 410" (not on the LAN 402) or "off-site". Service 408 may also be referred to as a local service.

[0046] LAN 402 is intended to represent a relatively local network of IoT devices and potentially other devices. Figure 1 IoT device 404 may be implemented in a manner similar to that described for IoT device 104. Figure 1 For IoT controller 106 or reference Figure 2 The IoT controller engine 406 is implemented in a manner similar to that described for the IoT controller 206. The firewall 410 is intended to represent an example of a device located between local devices of the LAN 402 (such as the IoT device 404 or the IoT controller engine 406) and off-site devices of the WAN 412 (such as the IoT application controller engine 414).

[0047] Can be used with reference Figure 1 For IoT controller 106 or reference Figure 3 The IoT application controller engine 414 is implemented in a manner similar to that described for the IoT application controller 310. In the diagram 400, the IoT application controller engine 414 includes: a load balancer 416, a front-end application engine 418 coupled to the load balancer 416, services 420-1 to 420-n (collectively referred to as services 420) coupled to the front-end application engine 418, and an API gateway 422 coupled to the load balancer 416 and the front-end application engine 418.

[0048] The front-end application engine 418 is intended to represent the front-end interface of the service 420. (The front-end application engine 418 and the service 420 may be collectively referred to as an application server.) In a specific implementation, the front-end application engine 418 may include a web server based on, for example, the Simple Object Access Protocol (SOAP). Alternative implementations include: a messaging server, a Representational State Transfer (RESTful) HTTP server, an OPC Unified Architecture (OPC-UA), Windows Communication Foundation (WCF), Apache Thrift, and SORCER.

[0049] In a particular implementation, the event capture engine is coupled to the LAN 402 at the location identified by arrow 424 (i.e., the inspector is "on the LAN 402" and may be referred to as a local inspector). In such an implementation, it would not be uncommon for network traffic to be transmitted in plain text between the IoT device 404 and the IoT controller engine 406. For example, the inspector may be implemented as a sniffer capable of detecting network traffic between the IoT device 404 and the IoT controller engine 406.

[0050] In a particular implementation, the event capture engine is operably connected to the IoT application controller engine 414 at the location identified by arrow 426. In such an implementation, the checker is located "behind" the load balancer 416 (and may be referred to as an application load balancer checker), and the checker is located between the front-end application engine 418 and each of the services 420 (e.g., each of the services 420 is preceded by a checker, which may be referred to as an application service checker). "Behind" is intended to mean that the load balancer 416 is between the checker and the IoT device 404.

[0051] Reference again Figure 1 , the event capture engine 108 is intended to include a set of inspectors located at various locations throughout the network, such as reference Figure 2-4 Described. Depending on implementation-specific, configuration-specific or other factors, it may be desirable that the event capture engine 108, or at least its inspectors, be lightweight, making it easier to deploy as many inspectors as possible without difficulty and to correlate events associated with activities across multiple inspectors. In a particular implementation, the associated event generating components are co-located with their respective inspectors, which may include local inspectors, application load balancer inspectors, and / or application service inspectors.

[0052] The event data store 110 is intended to represent a data store of events at any stage of transformation (from raw events to normalized, aggregated, enhanced and / or otherwise transformed events). The smallest unit of identification of an IoT device can be characterized as an event. The event data structure may or may not include representations of events that are not network events, such as local database access events, events obtained from (one or more) log messages via activity queries, and the like. Because the network session of the IoT device 104 of the IoT device is a network event (or a persistent network session can be "chunked" into a series of network events), the IoT device can be identified as a participant in an activity defined by the following: the event at least partially matches the relevant event data structure in the event data store 110 representing the network event of the IoT device. As used herein, an activity data structure is a tag set of events. The IoT application behavior is sufficiently different from the IoT device behavior, and the smallest meaningful identification unit of the IoT application is an activity (e.g., file download). In an example of operation, the event capture engine 108 stores the captured events in the event data store 110, which can initially be referred to as a "raw event".

[0053] The IoT signal feature generation engine 112 is intended to represent an engine that converts raw events in the event data store 110 into IoT signal features. In a particular implementation, the IoT signal feature generation engine 112 is co-located with the event capture engine 108 for convenience. For example, it is convenient to normalize the events at the time of capture, perform at least some aggregation on the normalized events, and extract at least some signal features from the normalized (and possibly aggregated) events. Alternatively or in addition, the aggregation and feature extraction are performed via components in the IoT signal feature generation engine 112 that are remote from the event capture engine 108.

[0054] Figure 5 A diagram 500 of an example of an IoT signal feature generation engine is depicted. The diagram 500 includes a raw event data store 502, an event normalization engine 504 coupled to the raw event data store 502, a domain data store 506 coupled to the event normalization engine 504, a normalized event data store 508 coupled to the event normalization engine 504, an event aggregation engine 510 coupled to the domain data store 506 and the normalized event data store 508, an aggregated event data store 512 coupled to the event aggregation engine 510, an IoT signal feature extraction engine 514 coupled to the domain data store 506 and the aggregated event data store 512, and an IoT signal feature data store 516 coupled to the IoT signal feature extraction engine 514. Some of the components illustrated in the diagram 500 may be implemented in whole or in part at a different physical location than other components.

[0055] The raw event data store 502 is intended to represent various kinds of events. An important subclass of events is network session events or "network events." In some implementations, network events may be appropriately referred to as "packet-based" (or "frame-based") events because network event capture is in packets or frames. In a particular implementation, a discrete network event is a network session. Alternatively or in addition, a discrete network event is a portion of a persistent network session that has been broken into chunks, where the chunks of the network session collectively constitute the network session. Another potential subclass of events includes message transport events, such as messages that use a lightweight publish / subscribe messaging transport (e.g., Message Queuing Telemetry Transport (MQTT)). Another potential subclass of events includes message log events, such as messages that use a standard to separate message generators, systems that store messages, and message analysis and reporting engines (e.g., syslog). The raw event data store 502 can be thought of as a "super" data store (such as Figure 1 110 ), which incorporates other data stores, such as a normalized event data store 508 , an aggregated event data store 512 , and an IoT signal feature data store 516 .

[0056] Event normalization engine 504 is intended to represent an engine that normalizes events of different formats. Event normalization engine 504 uses information from domain data store 506 to determine the normalized (e.g., standardized) format of the event, and normalizes (e.g., converts) the event from raw event data store 502 for storage in normalized event data store 508. In a specific implementation, events are normalized using one or more of a timestamp, a tag (e.g., from domain data store 506), an ID (e.g., a user ID or event ID), etc. Normalizing events enables subsequent engines to perform a comparison of events of the same category, for example, for aggregation purposes. In implementations that, for example, aggregate only network events, normalization may or may not be considered optional.

[0057] Event aggregation engine 510 is intended to represent an engine for aggregating normalized events from normalized event data store 508 with other related events. In a particular implementation, the other related events are also normalized events in normalized event data store 508. Related events may include, for example, multiple discrete network events of a persistent session; events associated with the same source, user, time, or application; events that may be related to an activity (e.g., login, download, streaming, or other possible activities) (based on, for example, domain knowledge); events associated with an IoT device profile; events related to a time series level, and so on. Event aggregation engine 510 stores the aggregated events in aggregated event data store 512. Note that an "aggregated event" may include one or more normalized events, and the context will indicate whether this means that an aggregated event includes one normalized event or an aggregated event includes multiple normalized events.

[0058] The IoT signal feature extraction engine 514 is intended to represent an engine for extracting features from signals associated with IoT devices. In a specific implementation, although a given signal may have multiple associated features, for the purpose of determining periodicity, the signal is considered to be a minimal event or atomic event. For example, a five-minute transform may be considered to have five signal features associated with each of the five minutes. The feature value includes a data sample corresponding to the feature itself. The IoT signal feature extraction engine 514 stores the feature value in the IoT signal feature data store 516.

[0059] In the example of operation, the events are assumed to be network session events. The event normalization engine 504 (if applicable) normalizes the amount of events (e.g., a number of bytes) within a time span (e.g., a five minute interval). The event aggregation engine 510 aggregates one or more events captured during the time span. It may be noted that events that are not aggregated may still be analyzed by the IoT signal feature extraction engine 514 along with any aggregated events. The extracted signal features, which may be characterized as aggregated, normalized, enriched, or otherwise transformed events, are used to identify periodic activity, such as with reference to Figure 6 as described.

[0060] Figure 6Diagram 600 depicts an example of a periodic activity definition engine. Diagram 600 includes: an IoT signal feature data store 602, an IoT signal generation engine 604 coupled to the IoT signal feature data store 602, a background event context data store 606 coupled to the IoT signal generation engine 604, signal data stores 608-1 to 608-n (collectively referred to as signal data stores 608) coupled to the IoT signal generation engine 604, a periodic discovery engine 610 coupled to the signal data store 608, periodic activity instance data stores 612-1 to 612-n (collectively referred to as periodic activity instance data stores 612) coupled to the periodic discovery engine 610, a periodic activity generation engine 614 coupled to the periodic activity instance data store 612, external context data stores 616-1 to 616-n (collectively referred to as external context data stores 616) coupled to the periodic activity generation engine 614, a periodic activity data store 618 coupled to the periodic activity generation engine 614, and a context extraction engine 620 coupled to the external context data store 616.

[0061] The signal feature data store 602 is intended to represent a data store of an event data structure, which includes a start time value, an end time value, an interval value, and an interval fluctuation (referred to herein as a time increment) value. (It may be noted that at this stage, the values ​​may or may not be understood to be relevant.) Normalization can facilitate the creation of periodic descriptors for different types of events (e.g., network, message queue, syslog, etc.). In a specific implementation, the start time is a timestamp attributed to the start of a periodic activity (which may be the same as the start of the first detected event of the activity), the end time is a timestamp attributed to the end of the periodic activity (the value may be considered to be blank or empty until such time when the activity stops), the interval is the time span between two periodic events (or two aggregated events), and the time increment is an acceptable deviation from the interval. "Acceptable deviation" means that the attribution of periodicity can be applied even if the interval between detected events varies slightly, although the amount of change will depend on the complexity of the system (in general, the larger the time increment of the interval between periodic events, the more difficult it is to identify periodicity). Thus, the signal signature of a given (potentially periodic) sequence of events can be characterized as multiple event queues in a time window defined by a start time and separated by time intervals having deviations from expected intervals within a time increment. Depending on implementation-specific, configuration-specific, or other factors, an activity can have multiple different periodicities, which can be tracked and correlated separately.

[0062] In a specific implementation, the interval and time increment values ​​are implemented as minimum intervals, and the time increment is implemented as the maximum time after the minimum interval during which a periodic event occurs (e.g., the start time of the next event must occur at the time of the indicated interval or after the indicated interval, but before the time of the interval + the time increment). In an alternative, the interval is implemented as a maximum interval, and the time increment is implemented as a time frame before the maximum interval. As yet another alternative, the interval is implemented as a predicted interval, and the time increment is implemented as an acceptable time before or after the predicted interval during which a periodic event occurs (and, in this alternative, the time increment may or may not have two values, one for before the indicated interval, and one for after the indicated interval).

[0063] IoT signal generation engine 604 generates a signal using the signal features in IoT signal feature data store 602 and context from background event context data store 606. Background event context data store 606 is intended to represent a data store that includes an IoT device identifier (ID), application ID, and volume; the background event context may or may not include a user ID and source ID. In an alternative solution, a domain data store (see, e.g., Figure 5 ) The background event context can be explicitly embedded in the signal features, thereby logically rendering the background event context data store 606 as part of the IoT signal feature data store 602.

[0064] A signal can be defined as one or more events that are time-correlated on an activity timeline that are above an event correlation threshold. In a specific implementation, the event correlation threshold is trained from samples. Depending on the implementation, configuration, or other factors, parameters can affect the event correlation threshold (for example, different thresholds can be applied to different features). (As mentioned later, an activity can be defined as one or more events that are time-correlated on an activity timeline and context). In a specific implementation, (one or more) signals are represented as application-specific Boolean arrays of IoT devices and sources over a time span. Because in this specific implementation, the signals are application-specific, events related to the first application are not part of the array for the second application.

[0065] The IoT signal generation engine 604 stores the signals in a signal data store 608. For ease of illustration, the signal data store 608 is represented as a plurality of distinct data stores 608-1 to 608-n, each of which is intended to represent a signal associated with a particular application, IoT device, and source. For the purposes of periodic discovery, non-periodic signals may be considered noise (although they may of course be relevant to other aspects of IoT network analysis or security). In a particular implementation, the data structure of the signal data store 608 includes Boolean arrays corresponding to (historical) events, which are fed one by one into the periodic discovery engine 610.

[0066] The periodicity discovery engine 610 is intended to represent an engine that analyzes various time spans associated with IoT devices, applications, and sources to discover periodicities associated with IoT devices, applications, and sources. Advantageously, because the periodicity discovery engine 610 analyzes various time spans, it is possible to detect periodicities within a first time span that do not necessarily repeat over a second time span. For example, an activity may have a weekly periodicity that would not be detected with a time span of only one day; a security agent may report daily (first time span) and check for version updates weekly (second time span), so a single application may have multiple different periodicities that are detectable over different time spans. As discussed later, this allows for correlation and different considerations if a first activity (e.g., daily reporting) and a second activity (e.g., weekly checking) are no longer detectable as expected.

[0067] In a specific implementation, the periodicity discovery engine 610 uses a Fourier transform algorithm to identify periodicity. It is possible to calculate s over interval N. n Discrete Fourier Transform (DFT): f k = K / N, where N is the sample and K is the segment. The Fourier transform algorithm can be accurate in the case of relatively small intervals, but this is not absolutely necessary in IoT applications because IoT is relatively stable (and DFT cannot distinguish signal from noise). Therefore, as has been advantageously demonstrated experimentally, a potentially more desirable alternative is to use the p-score alone after the DFT, or to use the PSD or non-Gaussian distribution (used to find possible locations of peaks).

[0068] In the case of the p-score based algorithm, the timeline T is divided into segments K for samples N. Notable formulas that can be understood by those skilled in the relevant art include: i =(fragment in time slot i) / K and P k =Δt / f k, where Δt = 5 minutes, 1 hour or 1 day (or some other useful time interval), k = n consecutive samples, K·n = N, f k = K / N. In the example of operation, it is assumed that the period is "n" (Note: n is the sampling interval s0 to s i to n-1 , where i is the sampling interval index, and P{i} = S / K, where S is s i number of segments in , and try to get n=1 to a value of perhaps a week of samples; use probability to determine the start time.

[0069] One can also use exponential distribution or other regression algorithms. For example, as another alternative, one can use autocorrelation (time series correlation) alone to find the relationship with delayed copies. After shifting the signal and checking the number of signals, if there is overlap, the shift will produce the same number of signals of larger magnitude. This technique can also be used in conjunction with other algorithms. In any case, a threshold is trained from the samples and incorporated into the algorithm to enable detection of the signal, such as Figure 7 as shown in the example of .

[0070] Figure 7 A graph 700 illustrating event detection over time is depicted. The graph 700 includes a time axis 702 and a probability axis 704. As time passes, events occur, which can be represented as spikes or rectangles on the graph, with start and stop times that are conceptually comparable to units on the time axis 702. Depending on the desired conceptualization, wider events can be characterized as transmitting more bytes or more messages. Taller events can be characterized as being more unique (e.g., more abnormal), which can be conceptually related to units on the probability axis 704.

[0071] For illustrative purposes, graph 700 has been populated with events 706 and normal activity 708. Because events 706 exceed threshold 710, they are distinguishable from normal activity 708. Figure 7 In the example of FIG. 7 , some of the events 706 are components of a signal 712 associated with an activity (e.g., FTP). Other events 706 are components of a signal 714 associated with some other activity (e.g., Figure 7 , signal 714 comprises a single event in the illustrated timeline). Normal activity 708 may be characterized as “background activity,” which is those activities for which the characteristic value will not exceed threshold 710. Background activity, which may include normal events that occur all the time, will become contextual in the sense that they can be used to determine what is abnormal activity. Figure 7As shown, a signal can be characterized as one or more events related in time on an activity timeline above a threshold. Although a signal can be associated with an "activity", it should be understood that an activity is one or more events related in time on an activity timeline in context, so although the term "activity" can be used to describe a signal because it will ultimately be identified as an activity, the activity may or may not yet be fleshed out for a signal.

[0072] Reference again Figure 6 In the example of , the output of the periodicity discovery engine 610 is the actual periodicity of a particular IoT device, source, and application, which is stored in the periodic activity instance data store 612. At this stage, for a given signal with characteristics that fall within the indicated parameters, the start time value, end time value, interval value, and interval fluctuation (referred to herein as time increment) value are identified (although the end time remains null until the activity actually stops). A periodic activity instance descriptor can be defined as a data structure stored in the periodic activity instance data store 612 that describes an activity using its start time, end time, interval, and time increment.

[0073] The periodic activity generation engine 614 is intended to represent an engine that generates a periodic activity data structure using an external context data store 616 for storage in a periodic activity data store 618. In a specific implementation, the periodic activity generation engine 614 performs cross-feature correlation and grouping to form identified activities. Events can be grouped by device, application, source IP, transmission volume, etc. The purpose of grouping is to find related signals. Therefore, an activity can be defined as a related signal plus context (e.g., FTP login). Advantageously, the periodic activity generation engine 614 can detect not only the periodicity of the activity, but also the periodicity of the context.

[0074] As mentioned above, periodic activity can be associated with security agents that have activity with different periodicity. Moreover, when one IoT device of a group has a different periodicity than the other devices in the group, profiling the group behavior can help discover anomalous periodicity, whether due to lack of periodicity (e.g., nine IoT devices of a group have periodicity and the tenth IoT device has no periodicity, which can identify misclassification of IoT devices, configuration issues, malicious activity, repurposing of IoT devices to do things not expected, etc., resulting in IoT devices being reported as exhibiting anomalous behavior); unknown periodicity (e.g., an IoT device has a three-hour repeating message pattern to an unknown domain, which indicates unauthorized installation, malware, etc.); or a change in periodicity (e.g., an IoT device starts sending messages three times a day instead of once a day, which can indicate a configuration change, a change in activity (such as more frequent reports due to more frequent accumulation of data), a patch / version change not responding to automatic installation, a mobile machine causing it to make home calls more frequently, which indicates a network configuration failure and therefore more attempts to call home).

[0075] In certain implementations, machine learning and, in more certain implementations, clustering are used to convert the signals into activities (eg, using clustering and then labeling each group).

[0076] In a particular implementation, the periodic activity generation engine 614 is associated with external context such as other IoT service activities (e.g., one application can trigger another application). The external context data store 616 includes, for example, network environment (e.g., VLAN segmentation) parameters, activity scan results (e.g., discovery / vulnerability lists), device personality (e.g., OS, firmware, vendor, identity, type, behavior), endpoint state (e.g., Symantec endpoint solution integrated with API to understand what is happening on the device), reputation intelligence (e.g., IP address reputation; categories such as business, AWS, entertainment, etc.; threats by device type, version, etc.; and / or published device vulnerabilities or characteristics), application activity (e.g., activity of applications associated with related events), user information, etc. Some of these parameters may be considered as background event context instead or in addition (e.g., redundantly). The external context data store 616 may be characterized as including data that can be derived from inactive signals; the context extraction engine 620 is intended to represent an engine that extracts such context. In a particular implementation, context extraction and signal generation are performed in parallel. The external context may be different for each signal, and thus the external context data store 616 is represented as a plurality of conceptually distinct data stores 616 - 1 through 616 - n .

[0077] In a specific implementation, activity generation entails the generation of an activity definition, which includes a list of features and value ranges (and can be characterized as a classifier). The generated activity descriptor can include an activity ID (or a periodic activity ID, which is obtained after the periodicity is detected and used as a handle, usually for the benefit of a human administrator), multi-dimensional merged feature values, feature value ranges (e.g., low, average, high), device ID, application ID, user ID (which triggered the activity), sampling interval (e.g., predefined aggregation intervals of 5 minutes, 1 hour, 1 day, etc.), feature class, feature group, feature priority, algorithm used to classify the activity, timestamp, time interval, and time increment, to name a few parameters. Multi-dimensional means that there are multiple features in the model to identify periodicity and multiple related periodicities.

[0078] The abnormal periodic activity IoT network threat assessment engine 120 is intended to represent an engine that tracks periodic activity over time. If the expected periodic activity is not detected, its lack is considered abnormal and the abnormal periodic activity IoT network threat assessment engine 120 generates an alert. External context can help a person or artificial agent assess the threat level, which may affect whether an alert is raised. It is possible to have both malicious and benign repetitive patterns. (Previously undefined periodic activity can also be considered abnormal, but detecting previously undefined periodic activity can also be considered part of the functionality of the periodic activity generation engine 116, which can define the activity as malicious or benign.) Advantageously, using activity descriptors, the abnormal periodic activity IoT network threat assessment engine 120 can use anomaly detection to detect periodic changes. In operation, the abnormal periodic activity IoT network threat assessment engine 120 implements ripple detection, which is the detection of constructive heartbeats associated with IoT devices that exhibit periodic behavior that has previously been undetected on the IoT network and simply fluctuates.

[0079] Figure 8 A flowchart 800 of an example of a method for IoT periodic activity learning is depicted. Flowchart 800 and other flowcharts described herein have modules that can be reordered in terms of sequence or reorganized into parallel sequences if applicable.

[0080] Flowchart 800 begins at module 802, where IoT events are captured, at least some of which are associated with a first IoT device and a first IoT application. In a particular implementation, events are detected via passive monitoring. A fairly trivial type of detected discrete event might be a message sent to or from a first IoT device to a first IoT application controller. It may be desirable to focus on detecting discrete events that take relatively few resources to characterize, such as information in a packet header, although other more resource-intensive techniques (such as deep packet inspection (DPI)) may also be used to obtain even more event data. Depending on implementation-specific and other considerations, the events that are then used for the purpose of IoT application learning or IoT application activity orchestration may or may not include only discrete events. In any case, an activity is a collection of events with a label. In contrast to discrete events, a fairly trivial example of an aggregate event is a collection of heartbeat messages periodically sent by a first IoT device and treated as a single (aggregate) event. However, an aggregate event may be much more complex and even incorporate data that will not necessarily be associated with the first IoT device (or first IoT application controller), but will be used to determine the correlation between the first IoT application and an otherwise unrelated event that has been identified. In a particular implementation, discrete events are aggregated using machine learning to form aggregated events. Common factor aggregation is a method of applying various different machine learning and deep learning algorithms by focusing on common factors (such as all devices with the same profile, the same OS, using Windows, using telnet, all devices talking to a specific subnet, to name a few), as applied to both detected behavior and modeled behavior. For example, session events may be aggregated. In another example, streaming events may be aggregated. Events may be aggregated locally relative to a first IoT application. For example, events may be aggregated by a device implemented as part of a LAN with a first IoT device to form an aggregated event. It should be noted that tagged aggregated events may be referred to herein as "activities," but more generally, an activity is a tagged collection of one or more events, which may be discrete or aggregated. Module 802 may be implemented by an event capture engine such as Figure 1 The event capture engine 108) executes.

[0081] Flowchart 800 continues to module 804, where IoT signal features are generated from the IoT events, at least some of which are associated with activities of the first IoT device and the first IoT application. One or more of the IoT signal features can be used as a signature for the first IoT device and the first IoT application. Conceptually, activities can be characterized as streaming, file uploading, management, and the like along with features and / or major trends (e.g., for a security camera application, streaming may dominate). In a particular implementation, the population of activities is refined into a relatively small set (e.g., the defined activities may be limited to one hundred or fewer typically human-readable aggregate events such as logins, authentications, update requests, downloads, installations, etc.). In a particular implementation, multiple lightweight engines focus on a corresponding plurality of activities (e.g., downloads) or a relatively common subset of activities (e.g., Download). Each of these activities will have a set of signal characteristics applicable to them. This can be done by Figure 1 Module 804 may be executed by an IoT signal feature generation engine such as IoT signal feature generation engine 112 .

[0082] Flowchart 800 continues to module 806, where background event context is extracted from the IoT event. Module 806 may be performed by, for example, Figure 1 The IoT signal feature generation engine 112 or the like may be used to execute the IoT signal feature generation engine.

[0083] Flowchart 800 continues to block 808, where IoT signal features and background event context are used to generate periodic activity instance descriptors. Block 808 may be performed by, for example, Figure 1 The periodic activity definition engine 116 of the embodiment of the present invention may be executed by a periodic activity definition engine such as Figure 6 The process may be performed by a periodic discovery engine such as the periodic discovery engine 610.

[0084] Flowchart 800 continues to block 810, where external context is extracted from inactive IoT events. Inactive IoT events are those events that are not part of the IoT signal under consideration. Block 810 may be performed by, for example, Figure 1 The periodic activity definition engine 116 of the embodiment of the present invention may be executed by a periodic activity definition engine such as Figure 6 The context extraction engine 620 and the like may be used to perform the execution.

[0085] Flowchart 800 continues to block 812, where a periodic activity is defined using a periodic activity instance descriptor and an external context. Block 812 may be implemented by, for example, Figure 1 The periodic activity definition engine 116 of the embodiment of the present invention may be executed by a periodic activity definition engine such as Figure 6 The process may be executed by a periodic activity generation engine such as the periodic activity generation engine 614.

[0086] Flowchart 800 continues to module 814, where the detected activity is matched with the expected periodicity. Flowchart 800 is intended to represent a continuous process in which the same events analyzed to determine the periodicity are also matched with the expected periodicity. However, it can be noted that the machine learning techniques used to determine the periodicity can occur offline, while matching the signal with the known periodicity can occur in real time. If the detected activity cannot be matched with the expected periodicity, an alarm may be generated indicating that the expected periodic activity has not been detected. If this failure occurs once to a given number of times (depending on preference), an alarm may be generated indicating that the expected periodic activity has stopped. The detected activity can also be matched with known malicious periodic activities, and an alarm can be generated when it matches. Therefore, "abnormal" can refer to the lack of expected periodic events or the presence of periodic events that violate policies. Module 814 can be executed by an abnormal periodic activity IoT network threat assessment engine such as abnormal periodic activity IoT network threat assessment engine 120.

[0087] The techniques described in the preceding text and figures can be mixed and matched to produce alternative implementations as circumstances require.

Claims

1. A method comprising: capturing an IoT event associated with a first IoT device and a first IoT application; generating IoT signal features from the IoT events, at least some of the IoT signal features being associated with activities of the first IoT device and the first IoT application; Extracting background event context from IoT events; Generate periodic activity instance descriptors based on IoT signal features and background event context; Extract external context from inactive IoT events; identifying a periodic activity of the first IoT device based on the periodic activity instance descriptor and the external context; determining an expected periodicity of a periodic activity of the first IoT device; Detecting the activity of the first IoT device; The detected activity of the first IoT device is matched to the expected periodicity.

2. The method according to claim 1, further comprising: If the periodicity of the detected activity of the first IoT device fails to match the expected periodicity, an alert is generated.

3. The method according to claim 1, further comprising: If the periodicity of the detected activity of the first IoT device matches the expected periodicity of periodic activity known to be malicious, an alert is generated.

4. A system comprising: an event capture engine configured to capture IoT events associated with a first IoT device and a first IoT application; The IoT signal feature generation engine is configured to: generating IoT signal features from the IoT events, at least some of the IoT signal features being associated with activities of the first IoT device and the first IoT application; Extracting background event context from IoT events; a periodicity discovery engine configured to generate periodic activity instance descriptors based on IoT signal characteristics and background event contexts; a content extraction engine configured to extract external context from inactive IoT events; A periodic activity generation engine configured to: identifying a periodic activity of the first IoT device based on the periodic activity instance descriptor and the external context; determining an expected periodicity of a periodic activity of the first IoT device; An abnormal periodic activity IoT network threat assessment engine, which is configured to: Detecting the activity of the first IoT device; The detected activity of the first IoT device is matched to an expected period.

5. The system according to claim 4, wherein: Abnormal Periodic Activity The IoT network threat assessment engine is configured to generate an alert if the periodicity of the detected activity of the first IoT device fails to match the expected periodicity.

6. The system according to claim 4, wherein: Abnormal Periodic Activity The IoT network threat assessment engine is configured to generate an alert if the periodicity of the detected activity of the first IoT device matches the expected periodicity of periodic activity known to be malicious.

7. The system according to claim 4, wherein: Abnormal Periodic Activity The IoT network threat assessment engine is configured to: monitor periodic activity of a first IoT device; If the expected periodic activity of the first IoT device fails to occur, an alert is generated.

8. The system according to claim 4, wherein: Abnormal Periodic Activity The IoT network threat assessment engine is configured to: monitor periodic activity of a first IoT device; If the periodicity of the periodic activity of the first IoT device deviates from the expected periodicity, an alert is generated.

9. The system according to claim 4, wherein: The expected periodicity is determined using a Fourier transform algorithm, a p-score based algorithm, or an exponential distribution algorithm.

10. A system comprising: means for capturing IoT events associated with a first IoT device and a first IoT application; means for generating IoT signal characteristics from IoT events, at least some of the IoT signal characteristics being associated with activities of a first IoT device and a first IoT application; Means for extracting background event context from IoT events; Means for generating periodic activity instance descriptors based on IoT signal characteristics and background event context; Means for extracting external context from inactive IoT events; means for identifying a periodic activity of a first IoT device based on the periodic activity instance descriptor and the external context; means for determining an expected periodicity of a periodic activity of a first IoT device; means for detecting activity of a first IoT device; Means for matching detected activity of a first IoT device to an expected periodicity.

Images