Automating IoT device identification using statistical payload fingerprints

Abstract

To provide a system, method and program which detect malware in various situations and prevent its harm for Internet of Things devices.SOLUTION: In a system, a security platform receives a byte frequency pattern associated with network traffic of an IoT device, uses the received pattern to determine a classification for the IoT device, and provides the classification to a security appliance. The security appliance is configured to apply a policy to the IoT device based at least in part on the classification.SELECTED DRAWING: Figure 7

Description

[Background technology]

[0001] CROSS-REFERENCE TO OTHER APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 033,012, filed June 1, 2020, entitled “IOT DEVICE CLASSIFICATION USING STATISTICAL FINGERPRINTS IN NETWORK TRAFFIC,” which is incorporated herein by reference for all purposes.

[0002] Nefarious individuals attempt to compromise computer systems in a variety of ways. As one example, such individuals may embed or otherwise contain malicious software ("malware") in email attachments and then send, or cause to be sent, the malware to unsuspecting users. When executed, the malware compromises the victim's computer and can perform additional nefarious tasks (e.g., extracting sensitive data, propagating to other systems, etc.). Various approaches are used to harden computers against such and other breaches. Unfortunately, existing approaches to securing computers are not necessarily suitable for all computing environments. Additionally, malware creators are constantly adapting techniques to evade detection, and there is a continuing need for improved techniques to detect malware and prevent its harm in a variety of situations. [Brief description of the drawings]

[0003] Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings. [Figure 1] Figure 1 shows an example of an environment where malicious activity can be detected and mitigated. [Figure 2A] FIG. 2A illustrates one embodiment of a data appliance. [Figure 2B] FIG. 2B is a functional diagram of logical components of one embodiment of a data device. [Figure 2C] FIG. 2C shows an example of an event path between an IoT server and an IoT module. [Figure 2D] FIG. 2D shows an example of a device discovery event. [Figure 2E] FIG. 2E shows an example of a session event. [Figure 2F] FIG. 2F illustrates one embodiment of an IoT module. [Figure 2G] Figure 2G shows one example of how IoT device analytics can be implemented. [Diagram 3] FIG. 3 illustrates one embodiment of a process for passively providing AAA support to IoT devices in a network. [Figure 4A] FIG. 4A illustrates an example of a RADIUS message sent by an IoT server on behalf of an IoT device to an AAA server in various embodiments. [Figure 4B] FIG. 4B illustrates an example of a RADIUS message sent by the IoT server on behalf of the IoT device to the AAA server in various embodiments. [Figure 4C] FIG. 4C illustrates an example of a RADIUS message sent by the IoT server on behalf of the IoT device to the AAA server in various embodiments. [Figure 5A] FIG. 5A shows an example of updating the byte frequency based on the payload of a packet. [Figure 5B] FIG. 5B shows an example of a raw byte count report. [Figure 6A] FIG. 6A shows an example of the byte frequency distribution of a device. [Figure 6B] FIG. 6B shows an example of the byte frequency distribution of a device. [Figure 6C] FIG. 6C shows an example of the byte frequency distribution of a device. [Figure 7] Figure 7 shows an example process for classifying IoT devices. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004] The present invention can be implemented in various ways, including a processor, such as an apparatus, a system, a composition of things, a computer program product embodied in a computer-readable storage medium, and / or a processor configured to execute instructions stored in and / or provided by a memory coupled to the processor. In this specification, these implementations, or other forms the present invention may take, are referred to as techniques. In general, the order of steps of a disclosed process may be modified within the scope of the present invention. Unless otherwise specified, components such as a processor or memory described as being configured to perform a task may be implemented as general components that are temporarily configured to perform the task at a given time, or as specific components manufactured to perform the task. As used herein, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0005] A detailed description of one or more embodiments of the present invention is provided below along with the accompanying figures that illustrate the principles of the present invention. Although the present invention will be described in conjunction with such embodiments, the present invention is not limited to any embodiment. The scope of the present invention is limited only by the claims, and the present invention encompasses numerous alternatives, modifications, and equivalents. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. These details are provided for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For the sake of clarity, technical materials known in the art related to the present invention have not been described in detail so as not to unnecessarily obscure the present invention.

[0006] A system and method are described. A byte frequency pattern associated with network traffic of an Internet of Things (IoT) device is received. In some aspects, the byte frequency pattern includes a byte flow distribution. In some aspects, the byte frequency pattern is determined based at least in part on a predetermined number of packets in the flow. In some aspects, the byte frequency pattern is determined using a transport layer payload. In some aspects, the byte frequency pattern is received from a data device configured to monitor the IoT device. The received pattern is used to determine a classification of the IoT device. In some aspects, the classification is determined based at least in part on a threshold match, which may be based on a number of features. In the event that the received pattern is determined to be within a threshold of an existing byte frequency pattern, the IoT device may be classified as another device associated with a profile. If the received pattern is determined to be outside the threshold of a number of existing byte frequency profiles, a new profile may be generated. In some aspects, the classification is determined at least in part based on a model. The model may be trained using a set of features including byte flow distribution information. The classification is provided to a security device configured to apply a policy to the IoT device based at least in part on the classification.

[0007] I. Overview

[0008] A firewall generally protects a network from unauthorized access while allowing authorized communications to pass through the firewall. A firewall is typically a device or set of devices, or software running on a device that provides firewall functionality for network access. For example, a firewall can be integrated into the operating system of a device (e.g., a computer, a smart phone, or other type of network-enabled device). Firewalls can also be integrated or run as software on computer servers, gateways, network / routing devices (e.g., network routers), and data appliances (e.g., security appliances or other types of special-purpose devices).

[0009] Firewalls typically deny or allow network transmissions based on a set of rules. These sets of rules are often referred to as policies. For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching a protected device. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify or log, and / or other actions can be specified in a firewall rule or firewall policy that can be triggered based on various criteria, as described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0010] A security device (e.g., a security appliance, a security gateway, a security service, or other security device) can include various security functions (e.g., firewalls, anti-malware, intrusion prevention / detection, data loss prevention (DLP), and / or other security functions), network functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, other network functions), and / or other functions. For example, a routing function can be based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

[0011] Basic packet filtering firewalls filter network communication traffic by inspecting each individual packet sent across a network (e.g., packet filtering firewalls or first generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect each individual packet itself and then apply rules based on the inspected packet (e.g., using a combination of the packet's source and destination address information, protocol information, and port numbers).

[0012] Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second generation firewalls that operate at the application level of the TCP / IP stack). Application layer filtering firewalls or application firewalls can generally identify certain applications and protocols (e.g., web browsing using the Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfers using the File Transfer Protocol (FTP), and various other types of applications and other protocols such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, application firewalls can block unauthorized protocols that attempt to communicate over standard ports (e.g., unauthorized / out-of-policy protocols trying to sneak in using non-standard ports for that protocol can generally be identified using an application firewall).

[0013] Stateful firewalls can also perform state-based packet inspection, where each packet is inspected within the context of the set of packets associated with that network transmission packet flow. This firewall technique is commonly referred to as stateful packet inspection because it keeps a record of all connections passing through the firewall and can determine whether a packet is the start of a new connection, part of an existing connection, or an invalid packet. For example, the state of a connection itself can be one of the criteria that triggers a rule in a policy.

[0014] Advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering, as described above. Next-generation firewalls can also perform additional firewall techniques. For example, certain new firewalls, sometimes referred to as advanced or next-generation firewalls, can also identify users and content (e.g., next-generation firewalls). In particular, certain next-generation firewalls have expanded the list of applications that they can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (e.g., Palo Alto Networks PA Series Firewalls). For example, Palo Alto Networks next-generation firewalls enable enterprises to identify and control applications, users, and content - not just ports, IP addresses, and packets - using a variety of identification technologies, such as APP-ID for precise application identification, User-ID for user identification (e.g., user or user group), Content-ID for real-time content scanning (e.g., controlling web surfing and restricting data and file transfers), and so on. These identification technologies allow enterprises to securely enable application usage using business-relevant concepts instead of following the traditional approach offered by traditional port-blocking firewalls. Additionally, special purpose hardware for next generation firewalls (implemented as dedicated appliances, etc.) generally offers higher performance levels for application inspection than software running on general purpose hardware (e.g., security appliances from Palo Alto Networks use dedicated, function-specific processing tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).

[0015] Advanced or next-generation firewalls can also be implemented using virtualized firewalls. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (e.g., the Palo Alto Networks VM Series firewalls, e.g., VMware® ESXi). TM and NSX TM , Citrix(R)Netscaler SDX TM It supports a variety of commercial virtualization environments, including , KVM / OpenStack (Centos / RHEL, Ubuntu(R)), and Amazon Web Services (AWS). For example, the virtualized firewall can support similar or identical next-generation firewall and advanced threat prevention capabilities available in physical form factor appliances, allowing enterprises to securely run applications in and across their private, public, and hybrid cloud computing environments. Automation capabilities such as VM monitoring, dynamic address groups, and REST-based APIs enable enterprises to proactively monitor VM changes and dynamically incorporate that context into security policies, thereby eliminating policy lag that can occur when VMs change.

[0016] II. EXAMPLE ENVIRONMENT

[0017] Figure 1 illustrates an example of an environment in which malicious activity is detected and its harm mitigated. In the example illustrated in Figure 1, client devices 104-108 are a laptop computer, a desktop computer, and a tablet that reside (respectively) within an enterprise network 110 of a hospital (also referred to as "Acme Hospital"). Data appliance 102 is configured to enforce policies regarding communications between client devices, such as client devices 104 and 106, and nodes outside of enterprise network 110 (e.g., those reachable via external network 118).

[0018] Examples of such policies include traffic shaping, quality of service, and policies governing the routing of traffic. Other example policies include security policies, such as policies requiring scanning for threats in incoming (and / or outgoing) email attachments, web site content, files exchanged through instant messaging programs, and / or other file transfers. In some embodiments, data device 102 is also configured to enforce policies with respect to traffic remaining within enterprise network 110.

[0019] Network 110 also includes a directory service 154 and an Authentication, Automation, and Accounting (AAA) server 156. In the example shown in FIG. 1, directory service 154 (also referred to as an identity provider or domain controller) uses Lightweight Directory Access Protocol (LDAP) or other suitable protocol. Directory service 154 is configured to manage user identity and credential information. One example of directory service 154 is a Microsoft Active Directory server. Other types of systems, such as a Kerberos-based system, can also be used in place of an Active Directory server, and the techniques described herein are adapted accordingly. In the example shown in FIG. 1, AAA server 156 is a Network Admission Control (NAC) server. AAA server 156 is configured to authenticate wired, wireless, and VPN users and devices to the network, evaluate and remediate devices for policy compliance before allowing access to the network, differentiate access based on roles, and then audit and report on who is on the network. One example of an AAA server 156 is a Cisco Identity Services Engine (ISE) server that utilizes Remote Authentication Dial-In User Service (RADIUS). Other types of AAA servers, including those that use protocols other than RADIUS, can be used in combination with the techniques described herein.

[0020] In various embodiments, the data device 102 is configured to listen (e.g., passively monitor messages) for communications to / from the directory service 154 and / or the AAA server 156. In various embodiments, the data device 102 is configured to communicate (i.e., actively exchange messages with) the directory service 154 and / or the AAA server 156. In various embodiments, the data device 102 is configured to communicate (e.g., actively exchange messages with) an orchestrator (not shown), which communicates with various network elements, such as the directory service 154 and / or the AAA server 156. Other types of servers may also be included in the network 110 and may communicate with the data device 102, if applicable. And, the directory service 154 and / or the AAA server 156 may also be omitted from the network 110 in various embodiments.

[0021] 1 as having a single data device 102, a given network environment (e.g., network 110) may include multiple embodiments of data devices, whether operating individually or in conjunction. Similarly, although the term "network" is generally referred to herein in the singular (e.g., as "network 110") for brevity, the technology described herein may be deployed in a variety of network environments of different sizes and topologies, including different combinations of networking technologies (e.g., virtual and physical), using different networking protocols (e.g., TCP and UDP) and infrastructures (e.g., switches and routers) across different network layers, where applicable.

[0022] Data device 102 can be configured to operate in conjunction with a remote security platform 140. Security platform 140 can provide a variety of services, including performing static and dynamic analysis on malware samples (e.g., via sample analysis module 124) and providing a list of signatures of known malicious files, domains, etc. to a data device, such as data device 102, as part of a subscription. As described in more detail below, security platform 140 can also provide information (e.g., via IoT module 138) related to the detection, classification, management, etc. of IoT devices present in a network, such as network 110. In various embodiments, the signatures, results of the analysis, and / or additional information (e.g., regarding samples, applications, domains, etc.) are stored in database 160. In various embodiments, security platform 140 includes one or more dedicated commodity hardware servers (e.g., having multi-core processors, 32G+ RAM, gigabit network interface adapters, and hard drives) running a typical server-class operating system (e.g., Linux). Security platform 140 may be implemented across a scalable infrastructure including multiple such servers, solid state drives or other storage 158, and / or other applicable high performance hardware. Security platform 140 may include multiple distributed components, including components provided by one or more third parties. For example, some or all of security platform 140 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3).Additionally, similar to data device 102, whenever security platform 140 is referred to as performing a task, such as storing data or processing data, it should be understood that a subcomponent or subcomponents of security platform 140 (individually or in cooperation with third party components) may cooperate to perform the task. As an example, security platform 140 may cooperate with one or more virtual machine (VM) servers to perform static / dynamic analysis (e.g., via sample analysis module 124) and / or IoT device functionality (e.g., via IoT module 138). An example of a virtual machine server is a physical machine containing commercially available server-class hardware (e.g., multi-core processors, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) running commercially available virtualization software, such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Additionally, the virtual machine server may be under the control of the same entity that manages security platform 140, but may also be provided by a third party. As an example, the virtual machine servers may rely on EC2, with the remainder of the security platform 140 being provided by dedicated hardware owned and under the control of the security platform 140 operator.

[0023] An example of a data device is shown in FIG. 2A. The example shown is a representation of the physical components included in the data device 102 in various embodiments. Specifically, the data device 102 includes a high-performance multi-core central processing unit (CPU) 202 and a random access memory (RAM) 204. The data device 102 also includes storage 210 (such as one or more hard disk units or solid-state storage units). In various embodiments, the data device 102 monitors the enterprise network 110 and stores (either in the RAM 204, the storage 210, and / or other suitable locations) information used in implementing the disclosed techniques. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policies and other configuration information, signatures, hostname / URL categorization information, malware profiles, machine learning models, IoT device classification information, and the like. The data device 102 may also include one or more optional hardware accelerators. For example, the data device 102 may include an encryption engine 206 configured to perform encryption and decryption operations, and one or more field programmable gate arrays (FPGAs) 208 configured to perform matching, function as a network processor, and / or perform other tasks.

[0024] The functionality described herein as being performed by the data device 102 may be provided / implemented in a variety of ways. For example, the data device 102 may be a dedicated device or a set of devices. A given network environment may include multiple data devices, each configured to provide service to a particular portion of the network, capable of cooperating to provide service to a particular portion of the network, etc. The functionality provided by the data device 102 may also be integrated or executed as software on a general purpose computer, computer server, gateway, and / or network / routing device. In some embodiments, at least some functionality described as being provided by the data device 102 is instead (or additionally) provided to a client device (e.g., client device 104 or client device 106) by software executing on the client device. Functionality described herein as being performed by the data device 102 may also be performed, at least in part, by or in cooperation with the security platform 140, and / or functionality described herein as being performed by the security platform 140 may also be performed, at least in part, by or in cooperation with the data device 102, where applicable. As an example, various functions described as being performed by the IoT module 138 may be performed by an embodiment of the IoT server 134.

[0025] Whenever the data device 102 is described as performing a task, a single component, a subset of components, or all components of the data device 102 may cooperate to perform the task. Similarly, whenever a component of the data device 102 is described as performing a task, the subcomponent may perform the task and / or the component may cooperate with other components to perform the task. In various embodiments, portions of the data device 102 are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data device 102, various logical components and / or functions of the data device 102 may be omitted and the techniques described herein may be adapted accordingly. Similarly, additional logical components / functions may be included in embodiments of the data device 102, where applicable. One example of a component included in the data device 102 in various embodiments is an application identification engine configured to identify applications (e.g., using various application signatures to identify applications based on packet flow analysis). For example, the application identification engine may determine what type of traffic a session includes, such as web browsing-social networking, web browsing-news, SSH, etc. Another example of a component included in the data device 102 in various embodiments is the IoT server 134, described in more detail below. The IoT server 134 can take a variety of forms, including as a standalone server (or set of servers), either physical or virtualized, and may also be co-located / embedded with the data device 102, where applicable (e.g., as shown in FIG. 1).

[0026] 2B is a functional diagram of the logical components of one embodiment of a data device. The illustrated example is a representation of the logical components that may be included in the data device 102 in various implementations. Unless otherwise noted, the various logical components of the data device 102 may generally be implemented in a variety of ways, including as a set of one or more scripts (e.g., written in Java, Python, etc., as applicable).

[0027] As shown, the data appliance 102 constitutes a firewall and includes a management plane 212 and a data plane 214. The management plane is responsible for managing user interactions, such as by setting policies and providing a user interface for displaying log data. The data plane is responsible for managing data, such as by performing packet processing and session handling.

[0028] The network processor 216 is configured to receive packets from a client device, such as the client device 108, and provide them to the data plane 214 for processing. The flow module 218 creates a new session flow whenever it identifies a packet as being part of a new session. Subsequent packets are identified as belonging to the session based on the flow lookup. If applicable, SSL decryption is applied by the SSL decryption engine 220. Otherwise, processing by the SSL decryption engine 220 is skipped. The decryption engine 220 can help the data device 102 inspect and control SSL / TLS and SSH encrypted traffic, and thus help thwart threats that may otherwise remain hidden in the encrypted traffic. The decryption engine 220 can also help prevent sensitive content from leaving the enterprise network 110. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as URL category, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., specifying which sessions to decrypt), decryption profiles can be assigned to control various options for the sessions controlled by the policy, for example, requiring the use of specific cipher suites and encryption protocol versions.

[0029] The application identification (APP-ID) engine 222 is configured to determine what type of traffic a session includes. As an example, the application identification engine 222 may recognize a GET request in the received data and conclude that the session requires an HTTP decoder. In some cases, for example, during a web browsing session, the identified application may change, and such changes are recorded by the data appliance 102. For example, a user may first browse a corporate wiki (classified based on the visited URL as "web browsing-productivity") and then subsequently browse a social networking site (classified based on the visited URL as "web browsing-social networking"). Different types of protocols have corresponding decoders.

[0030] Based on the determination made by the application identification engine 222, the packets are sent by the threat engine 224 to the appropriate decoder, which is configured to assemble the packets (which may be received out of order) into the correct order, perform tokenization, and extract information. The threat engine 224 also performs signature matching to determine what happens to the packets. If necessary, the SSL encryption engine 226 can re-encrypt the decrypted data. The packets are forwarded using the forwarding module 228 for transmission (e.g., to a destination).

[0031] As also shown in FIG. 2B, policies 232 are received and stored in the management plane 212. The policies can include one or more rules, which can be specified using domains and / or host / server names, and the rules can apply one or more signatures or other matching criteria or heuristics, to enforce security policies for subscriber / IP flows based on various parameters / information extracted from the monitored session traffic flows. An interface (I / F) communicator 230 is provided for managing communications (e.g., via (REST) ​​APIs, messages, or network protocol communications or other communication mechanisms). The policies 232 can also include policies for managing communications related to IoT devices.

[0032] III. IOT DEVICE DISCOVERY AND IDENTIFICATION

[0033] Returning to FIG. 1 , assume that a malicious individual has created malware 130 (e.g., using system 120). The malicious individual hopes that a vulnerable client device will run a copy of the malware 130, compromising the client device and causing the client device to become a bot in a botnet. The compromised client device can then be instructed to perform tasks (e.g., mining virtual currency, participating in denial of service attacks, and propagating to other vulnerable client devices) and to report information or otherwise exfiltrate data to an external entity (e.g., a command and control (C&C) server 150) as well as receive instructions from the C&C server 150, if applicable.

[0034] Some of the client devices shown in FIG. 1 are commodity computing devices typically used within an enterprise organization. For example, client devices 104, 106, and 108 each run a typical operating system (e.g., macOS, Windows, Linux, Android, etc.). Such commodity computing devices are often provided and maintained by administrators (e.g., as company-issued laptops, desktops, tablets, respectively), and often operate in conjunction with user accounts (e.g., managed by a directory service provider (also referred to as a domain controller) that is configured with user ID and credential information). As an example, employee Alice may be issued a laptop 104 that she uses to access her ACME-related email and perform various ACME-related tasks. Other types of client devices (generally referred to herein as Internet of Things or IoT devices) are also increasingly present in networks, and are often “unmanaged” by IT departments. Such devices (e.g., teleconferencing devices) may be found across a variety of different types of enterprises (e.g., as IoT whiteboards 144 and 146). Such devices may also be vertical specific. For example, infusion pumps and computed tomography scanners (e.g., CT scanners 112) are examples of IoT devices that may be found within a healthcare enterprise network (e.g., network 110), and a robotic arm is an example of a device that may be found within a manufacturing enterprise network. Additionally, consumer-oriented IoT devices (e.g., cameras) may also exist within enterprise networks. Similar to commodity computing devices, IoT devices that exist within a network can communicate with resources that are internal or external to such network (or both, if applicable).

[0035] Like commodity computing devices, IoT devices are targets for nefarious individuals. Unfortunately, the presence of IoT devices in a network can present some unique security / management challenges. IoT devices are often low-power or special-purpose devices, and are often deployed without the knowledge of network administrators. Even when known to such administrators, endpoint protection software or agents may not be installed on the IoT devices. IoT devices may be managed by and communicate solely / directly with third-party cloud infrastructure using proprietary (or otherwise non-standard) protocols (e.g., industrial thermometer 152 communicates directly with cloud infrastructure 126). This can confound attempts to monitor network traffic to and from such devices to determine when a threat or attack against the device is occurring. Additionally, some IoT devices are mission-critical (e.g., in medical environments) or mission-critical (e.g., surgical systems connected to a network). Unfortunately, the compromise of an IoT device (e.g., by malware 130) or the misapplication of security policies to traffic associated with an IoT device can have devastating effects. The techniques described herein can be used to improve the security of heterogeneous networks that include IoT devices and to mitigate adverse effects on such networks.

[0036] In various embodiments, the data device 102 includes an IoT server 134. The IoT server 134, in some embodiments, is configured to cooperate with an IoT module 138 of the security platform 140 to identify IoT devices within a network (e.g., the network 110). Such identification can be used, for example, by the data device 102 to assist in creating and enforcing policies regarding traffic associated with the IoT devices, and to enhance the functionality of other elements of the network 110 (e.g., to provide contextual information to the AAA 156). In various embodiments, the IoT server 134 incorporates one or more network sensors configured to passively sniff / monitor traffic. One example of a way to provide such network sensor functionality is as a tap interface or a switch mirror port. Other approaches for monitoring traffic can also be used (additionally or alternatively), where applicable.

[0037] In various embodiments, the IoT server 134 is configured to provide logs or other data (e.g., passively collected from the monitoring network 110) to the IoT module 138 (e.g., via the front end 142). FIG. 2C illustrates an example of an event path between the IoT server and the IoT module. The IoT server 134 sends device discovery events and session events to the IoT module 138. Examples of discovery events and session events are illustrated in FIGS. 2D and 2E, respectively. In various embodiments, a discovery event is sent by the IoT server 134 whenever it observes a packet that can uniquely identify or confirm the identity of the device (e.g., whenever a DHCP, UPNP, or SMB packet is observed). Each session that the device has (with other nodes, whether inside or outside the device's network) is described in a session event that summarizes information about the session (e.g., source / destination information, number of packets received / sent, etc.). If applicable, multiple session events may be batched together by the IoT server 134 before sending to the IoT module 138. The example shown in Figure 2E includes two sessions: The IoT module 138 provides device classification information to the IoT server 134 via a device verdict event (234).

[0038] One example of how to implement the IoT module 138 is using a microservices-based architecture. The IoT module 138 can also be implemented using different programming languages, databases, hardware, software environments, if applicable, and / or as a messaging-enabled, context-constrained, autonomously developed, independently deployable, distributed, and automated process-built and released service. One of the tasks performed by the IoT module 138 is to identify IoT devices in the data provided by the IoT server 134 (and by other embodiments of data devices, such as data devices 136 and 148) and provide additional context information about those devices 148 (e.g., back to the respective data devices).

[0039] FIG. 2F illustrates one embodiment of an IoT module. Region 294 illustrates a set of Spark applications that run at intervals (e.g., 5 minutes, hourly, daily) across all tenants' data. Region 296 illustrates a Kafka message bus. Session event messages received by IoT module 138 (e.g., from IoT server 134) bundle together multiple events observed at IoT server 134 (e.g., to save bandwidth). Transformation module 236 is configured to flatten received session events into individual events and publish at 250. The flattened events are aggregated by aggregation module 238 using a variety of different aggregation rules. One example of a rule is "aggregate all event data for a particular device and each (APP-ID) application it uses for a time interval (e.g., 5 minutes)." Another example of a rule is "aggregate all event data for a particular device communicating with a particular destination IP address for a time interval (e.g., 1 hour)." For each rule, the aggregation engine 238 tracks a list of attributes that need to be aggregated (e.g., a list of applications used by a device or a list of destination IP addresses). A feature extraction module 240 extracts features (252) from the attributes. An analytics module 242 uses the extracted features to perform device classification (e.g., using supervised and unsupervised learning), the results (254) of which are used to power other types of analytics (e.g., via an operational intelligence module 244, a threat analytics module 246, and an anomaly detection module 248). The operational intelligence module 244 provides analytics related to OT frameworks and operational or business intelligence (e.g., how devices are being used). Based on the results of the analytics, an alert (256) may be generated. In various embodiments, MongoDB 258 is used to store the aggregated data and feature values.Background services 262 receive data aggregated by Spark applications and write the data to MongoDB 258. API server 260 pulls and merges data from MongoDB 258 to serve requests received from frontend 142.

[0040] FIG. 2G illustrates an example of how IoT device identification analysis can be implemented (e.g., in IoT module 138 as an implementation of analysis module 242 and related elements). Detection and session events (e.g., as shown in FIG. 2D and FIG. 2E, respectively) are received as raw data 264 on a message bus as a Kafka topic (and also stored in storage 158). Features are extracted by feature engine 276 (which can be implemented using Spark / MapReducer, for example). The raw data is enriched (266) with additional context information by security platform 140, such as location information (e.g., source / destination addresses). During metadata feature extraction (268), features are constructed, such as the number of packets sent from an IP address during a time interval, the number of applications used by a particular device during a time interval, and the number of IP addresses contacted by a device during a time interval. The features are passed in real time (e.g., over a message bus) to the inline analytics engine 272 (e.g., in JSON format) and then stored (e.g., in a feature database 270 in an appropriate format such as Apache Parquet / DataFrame) for subsequent querying (e.g., during offline modeling 299).

[0041] In addition to features built from metadata, a second type of feature can be built 274 by the IoT module 138, referred to herein as an analytic feature. An example of an analytic feature is one built over time based on time series data using aggregated data. The analytic features are also passed to the analytic engine 272 in real time and stored in the feature database 270.

[0042] An inline analytics engine 272 receives features on the message bus via a message handler. One of the tasks it performs is activity classification (278), which attempts to identify activities associated with the session (such as files downloaded, login / authentication processes, and disk backup activities) based on the received feature values / session information, and attaches any applicable tags. One way to implement activity classification 278 is via a neural network-based multi-layer perceptron in combination with a convolutional neural network.

[0043] Assume that the activity classification results in a determination that a particular device is engaged in printing activity (i.e., uses a printing protocol) and also periodically contacts HP owned resources (e.g., to check for updates by calling an HP URL and using it to report status information). In various embodiments, the classification information is passed to both a clustering process (unsupervised) and a prediction process (supervised). If either process results in a successful classification of the device, the classification is stored in the device database 286.

[0044] Devices may be clustered by a first stage clustering engine 280 into multiple clusters (e.g., behaves like a printer, behaves like an HP device, etc.) based on their attributes and other behavior patterns. One way to implement the clustering engine 280 is to use a gradient boosting framework (e.g., xgb). A first stage classifier may be useful for classifying devices that have not been seen before but are similar to existing known devices (e.g., a new vendor of thermostats starts selling a thermostat device that behaves similarly to a known thermostat).

[0045] As shown in FIG. 2G, the activity classification information is also provided to a set of classifiers 282, and a prediction is made based on the provided features of the device. Two possibilities can occur. In the first scenario, it is determined that there is a high probability that the device matches a known device profile (i.e., a high confidence score). If so, information about the device is provided to a second stage classifier (284), which makes a final decision on the device's identity (e.g., using the provided information and additional applicable contextual information) and updates the device database 286 accordingly. One way to implement the second stage classifier is to use a gradient boosting framework. In the second scenario, assume that the confidence score is low (e.g., the device matches both an HP printer and an HP laptop with 50% confidence). In this scenario, the information determined by the classifiers 282 can be provided to the clustering engine 280 as additional information that can be used in clustering.

[0046] Also shown in FIG. 2G is an offline modeling module 299. The offline modeling module 299 is contrasted with the inline analysis engine 272 because it is not time-constrained (whereas the inline analysis engine 272 attempts to provide device classification information (e.g., as messages 234) in real time). Periodically (e.g., once a day or once a week), the offline modeling module 299 (implemented using Python, for example) rebuilds the models used by the inline analysis module 272. The activity modeling engine 288 builds models for the activity classifier 278, which are also used for the device type model (296) used by the classifier for device identification during inline analysis. The baseline modeling engine 290 builds models of baseline behavior for the device model, which are also used when modeling specific types of device anomalies (292) and specific types of threats, such as kill chains (294). The generated models are stored in a model database 298, in various embodiments.

[0047] IV. Network Entity Identification AAA

[0048] As mentioned above, assume that Alice has been issued laptop 104 by ACME. Various components of network 110 work together to authenticate Alice's laptop as she uses it to access various resources. As an example, when Alice connects laptop 104 to a wireless access point (not shown) located in network 110, the wireless access point can communicate (directly or indirectly) with AAA server 156 while provisioning network access. As another example, when Alice uses laptop 104 to access ACME's email, laptop 104 can communicate (directly or indirectly) with directory service 154 while fetching her inbox, etc. As a commodity laptop running a commodity operating system, laptop 104 can generate appropriate AAA messages (e.g., RADIUS client messages) that help laptop 104 gain access to the appropriate resources it needs.

[0049] As mentioned above, one problem presented by IoT devices (e.g., device 146) in a network such as 110 is that such devices are often “unmanaged” (e.g., not configured, provisioned, not managed, etc., by a network administrator), do not support protocols such as RADIUS, and therefore cannot be integrated with AAA services like other devices such as laptop 104. Various approaches can be adopted to provide IoT devices with network access in network 110, each with drawbacks. One option is for ACME to restrict IoT devices to using a guest network (e.g., via a pre-shared key). Unfortunately, this can limit the utility of IoT devices if they cannot communicate with other nodes in network 110 to which they should legitimately have access. Another option is to allow IoT devices unrestricted access to network 110, but mitigates the security benefits of having a segmented network. Yet another method is for ACME to manually specify rules governing how a given IoT device can access resources in network 110. This approach is generally unsupported / impractical for a variety of reasons. As an example, administrators may often not be involved in the deployment of IoT devices and therefore may not know that policies for such devices should be included (e.g., in data appliance 102). Even if an administrator manually configures policies for a particular IoT device in appliance 102 (e.g., for a device such as device 112), keeping such policies up to date is error prone and generally unacceptable given the large number of IoT devices that may be present on network 110.Moreover, such policies are likely to be simplistic (e.g., assigning the CT scanner 112 to a particular network by IP address and / or MAC address) and do not allow for more granular control over connections / policies related to the CT scanner 112 (e.g., dynamically including policies that apply to surgical devices and point of sales (POS) terminals). Furthermore, even if the CT scanner 112 is manually included in the data device 102, as discussed above, IoT devices generally do not support technologies such as RADIUS, and the benefits of managing network access for the CT scanner 112 with such an AAA server are limited compared to other types of devices (e.g., laptop 104) that more fully support such techniques. As described in more detail below, in various embodiments, the data device 102 is configured to provide support for AAA functions to IoT devices present in the network 110 in a passive manner (e.g., via the IoT server 134).

[0050] In the following description, assume that Alice's department at ACME recently purchased an interactive whiteboard 146 so that Alice can collaborate with other ACME employees as well as individuals outside of ACME (e.g., Bob, a researcher at Beta University who has his own network 114, data device 136, and whiteboard 144). As part of the initial setup of the whiteboard 146, Alice connects it to a power source and provides a wired connection (e.g., to an outlet in the conference room) or wireless credentials (e.g., credentials for use by visitors to the conference room). Once the whiteboard 146 has provisioned a network connection, the IoT server 134 recognizes the whiteboard 146 as a new device in the network 110 (e.g., via mechanisms such as network sensors, as described above). One action taken in response to this detection is to communicate with the security platform 140 (e.g., create a new record for the whiteboard 146 in the database 160 and obtain currently available contextual information related to the whiteboard 146 (e.g., get the manufacturer of the whiteboard 146, the model of the whiteboard 146, etc.)). Any contextual information provided by the security platform 140 can be provided to (and stored by) the data device 102, which can then provide it to the directory service 154 and / or the AAA server 156, if applicable. If applicable, the IoT module 138 can provide updated contextual information about the whiteboard 146 to the data device 102 as it becomes available. And the data device 102 can provide ongoing information about the whiteboard 146 to the security platform 140 (e.g., via the IoT server 134) as well. Examples of such information include observations regarding the behavior of the whiteboard 146 on the network 110 (e.g., connection statistics), which can be used by the security platform 140 to build a behavior profile of a device such as the whiteboard 146.Similar behavioral profiles may be built by security platform 140 for other devices (e.g., whiteboard 144). Such profiles may be used for a variety of purposes, including detecting anomalous behavior. As an example, data appliance 148 may use information provided by security platform 140 to detect whether thermometer 152 is behaving anomalously compared to historical observations of thermometer 152 and / or compared to other thermometers (not shown) of a similar model, make, or more general nature, including thermometers present in other networks. If anomalous behavior is detected (e.g., by data appliance 148), appropriate remedial action may be automatically taken, such as restricting access of thermometer 152 to other nodes on network 116, generating an alert, etc.

[0051] 3 illustrates one embodiment of a process for passively providing AAA support to IoT devices in a network. In various embodiments, the process 300 is performed by the IoT server 134. The process begins at 302 when a set of packets transmitted by an IoT device is obtained. As an example, when the whiteboard 146 is initially provisioned in the network 110, such packets may be passively received by the IoT server 134 at 302. During subsequent use of the whiteboard 146 (e.g., when Alice is engaged in a whiteboard session with Bob via the whiteboard 144), packets may also be passively received at 302. At least one packet in the set of data packets is analyzed at 304. As an example of the processing performed at 304, the IoT server 134 determines that the packets received at 302 are transmitted by the whiteboard 146. One action that the IoT server 134 can take is to identify the whiteboard 146 as a new IoT device on the network 110 and obtain context information from the IoT module 138, if available. At 306, the IoT server 134 sends an AAA message on behalf of the IoT device that includes information associated with the IoT device. An example of such a message is shown in FIG. 4A. As mentioned above, the whiteboard 146 does not support the RADIUS protocol. However, the IoT server 134 can generate a message as shown in FIG. 4A on behalf of the whiteboard 146 (e.g., using the information received at 302 and also the information received from the security platform 140, if applicable). As mentioned above, once the IoT server 134 provides the IoT module 138 with information about the whiteboard 146, the IoT module 138 can take various actions, such as creating a record for the whiteboard 146 in the database 160 and populating the record with context information about the whiteboard 146 (e.g., determining the manufacturer, model number, etc.).As additional contextual information about the whiteboard 146 is collected by the security platform 140, the profile may be updated and propagated to the data device 102. When the whiteboard 146 is initially provisioned in the network 110, the additional contextual information may not be available (e.g., the security platform 140 may not have such additional information or such information may not be readily available to the IoT server 134 by the security platform 140). Thus, and as shown in FIG. 4A, a RADIUS message generated by the IoT server 134 on behalf of the whiteboard 146 may include limited information. As additional contextual information is received (e.g., by the IoT server 134 from the IoT module 138), subsequent RADIUS messages sent by the IoT server 134 on behalf of the whiteboard 146 may be enriched with such additional information. Examples of such subsequent messages are shown in FIG. 4B and FIG. 4C. 4B shows an example of a RADIUS message that the IoT server 134 can send on behalf of the whiteboard 146 once the context information for the whiteboard 146 (e.g., including a database of context information for various IoT devices) is provided by the IoT module 138. In the example shown in FIG. 4B, context information such as the manufacturer of the whiteboard (Panasonic) and the nature of the device (e.g., being an interactive whiteboard) is included. Such context information can be used by an AAA server, such as AAA server 156, to provide AAA services for the whiteboard 146 (without the need to modify the whiteboard 146), such as by automatically provisioning a subnetwork dedicated to videoconferencing equipment.Other types of IoT devices may also be automatically grouped based on attributes such as device type, purpose, etc. (e.g., critical surgical devices are automatically provisioned in a sub-network dedicated to such devices and thus isolated from other devices in the network). Such context information may be used to enforce policies such as traffic shaping policies, such as policies that give preferential treatment to whiteboard 146 packets over social networking packets (e.g., as determined using APP-ID). Fine-grained policies may be applied to communications with critical surgical devices as well (e.g., preventing the OS of devices communicating with such devices from becoming out of date). In the example shown in FIG. 4C, more context information is included in the RADIUS message by the IoT server 134 on behalf of the whiteboard 146. Such additional context information includes additional attribute information such as device model, operating system, and operating version. When the whiteboard 146 is initially provisioned in the network 110, all of the context information shown in FIG. 4C may not be available. As the whiteboard 146 is used in the network 110 over time, additional contextual information can be collected (e.g., because the IoT server 134 continues to passively observe packets from the whiteboard 146 and provide information to the security platform 140). This additional information can be leveraged (e.g., by the data device 102) to enforce fine-grained policies. As an example, as shown in FIG. 4C, the whiteboard 146 runs a particular operating system that is Linux-based and version 3.16. Frequently, IoT devices run non-upgradable / non-patchable versions of operating systems. Such devices may pose a security risk if exploits are developed against these operating systems.Based on the context information, the data device 102 can implement security policies, such as by isolating (or otherwise restricting access to) IoT devices having outdated operating systems from other nodes in the network 110, while allowing less restrictive network access to devices with current operating systems.

[0052] 4A-4C show examples of RADIUS Access-Request messages. Where applicable, the IoT server 134 can generate various types of RADIUS messages on behalf of the whiteboard 146. As an example, a RADIUS Accounting Start message can be triggered when traffic from the whiteboard 146 is first observed. Periodic RADIUS Accounting Interim-Update messages can be sent while the whiteboard is in use, and a RADIUS Accounting Stop message can be sent when the whiteboard 146 goes offline.

[0053] V. Automating IOT Device Identification Using Statistical Payload Fingerprinting

[0054] As described above, security platform 140 maintains (e.g., in database 160) various information that can be used to identify various types of IoT devices. Some devices (e.g., commodity consumer items) utilize common protocols / applications and can be easily identified (e.g., by security platform 140) using such information. Examples of such devices include printers, cameras, thermostats, and cleaning robots. As another example, radiology devices typically use a well-documented, non-proprietary data exchange protocol known as Digital Imaging and Communications in Medicine (DICOM). In various embodiments, IoT server 134 (or other elements, if applicable) includes a DICOM decoder that can decode DICOM traffic and extract various attributes (e.g., manufacturer identifier, DICOM implementation version, etc.) that can be used to identify a given radiology device.

[0055] Unfortunately, some IoT devices use proprietary technology, such as proprietary network protocols and applications, which may make identification more difficult. Examples of such devices in the medical industry include patient monitoring, nurse call systems, drug dispensing systems, vital signs monitoring, and telemedicine robots. Examples of such devices in the industrial and manufacturing industries include programmable logic controllers, automated guided vehicles, semiconductor manufacturing equipment, and robotic arms. Some specialized devices may use standard protocols and applications, while others may use protocols that are not understood by security platform 140. In various embodiments, security platform 140 can nonetheless classify such devices and enable data devices, such as data device 102, to enforce policies with respect to such devices.

[0056] A given byte (containing 8 bits) of network traffic has a value from 0 to 255. Different types of devices use different applications, which often have a unique set of frequently used bytes. In some cases, information about byte frequencies can be used to distinguish between traffic of various types of devices, without understanding the underlying meaning of the traffic.

[0057] Each application running on a device has a corresponding flow that can be observed by a data device (e.g., a TCP flow or a UDP flow is observed by the data device 102). In one example embodiment, for each flow, the IoT server 134 tracks the bytes in the payload as they are observed (e.g., incrementing the applicable count for each 0-255 byte in an array). An example of how to store such data is as a two-dimensional array (for each device), where the first dimension is the flow identifier and the second dimension is the byte value from 0-255. At the transport layer, a flow can be uniquely identified by a 5-tuple.<src_ip、src_port、dst_ip、dst_port、prot> where src_ip is the source IP address, src_port is the source port number, dst_ip is the destination IP address, dst_port is the destination port number, and prot is the protocol number. A hash table can be used to map each unique 5-tuple to an integer flow identifier. When a packet arrives, the 5-tuple in the transport layer header is used to look up the hash table and find the flow identifier if it exists, or create a new one if not. After determining the flow identifier, the corresponding byte frequency is updated based on the payload in the packet (as shown in FIG. 5A). Each entry in the hash table also has a field that indicates the number of packets that have been processed for the flow.

[0058] In some embodiments, the raw byte counts are reported (e.g., by the IoT server 134) to the security platform 140 (e.g., along with the device's MAC address and other information). An example of such a report (in JSON format) is shown in FIG. 5B. The byte counts are reported at the end of the flow, and can also be reported before the end of the flow (e.g., to reduce overhead). For many applications, the first n packets (e.g., 10 packets) contain the most unique application-specific or protocol-specific information, and the entire flow does not need to be analyzed. In various embodiments, the security platform 140 uses the received byte count information to determine a byte frequency distribution (BFD) for devices in the network 110, which can be used to automatically classify the devices (e.g., by comparing the BFD of a given device to information stored in the database 160). As previously described, in various embodiments, other components of the environment shown in FIG. 1 can perform such functions and applied techniques, if applicable, in various ways. As an example, in some embodiments, the BFD is determined locally by the IoT server 134 and then transmitted to the security platform 140, rather than being determined by the security platform 140.

[0059] Figures 6A-6C show example Byte Frequency Distributions (BFDs) for three devices: a Carefusion infusion pump, a Roche Point of Care (PoC) analyzer, and a GE Electrocardiogram (ECG) machine. The x-axis in each of Figures 6A-6C shows byte values ​​from 0-255. The y-axis in each of Figures 6A-6C shows the percentage of observed flows containing that byte value. For example, point (128, 0.01) indicates that 1% of all bytes in the observed traffic are 0x80 (byte value 128).

[0060] 7 illustrates an example process for classifying an IoT device. In various embodiments, process 700 is performed by security platform 140. Process 700 may also be performed by other systems, if applicable (e.g., systems located on-premise with the IoT device). Process 700 begins at 702 upon receiving a byte frequency pattern associated with the network traffic of the IoT device. As an example, portion 702 of process 700 occurs when an embodiment of IoT server 134 sends a BFD to security platform 140. As another example, portion 702 of process 700 occurs when security platform 140 generates or updates a BFD (e.g., in response to receiving message 500 from IoT server 134).

[0061] At 704, the received pattern is used to determine a classification for the IoT device. Various approaches can be used to perform this determination. As a first example, the pattern can be compared against a library of previously determined patterns (e.g., profiles stored in database 160 and generated from observations of known devices). If the received pattern matches a previously stored profile within a threshold, the IoT device can be classified accordingly. Accuracy can be improved by considering multiple features. As an example, any available static feature (such as an organizationally unique identifier (OUI)) can be considered when determining whether the received BFD matches a previously stored library profile. In this scenario, for example, the device is only classified at 704 as a particular brand of infusion pump if both the BFD matches a library profile within a threshold and the OUI of the device matches an OUI associated with the library profile. Additionally, portions 702 / 704 of process 700 can occur multiple times. For example, when a device is first added to a network, it may take some time (e.g., hours or days) for the device to comprehensively use its applications and for its byte frequency patterns to become representative of its communications. At 704, if a classification match is not initially found, the process may be repeated periodically with updated BFDs.

[0062] In various embodiments, a machine learning approach is used at 704. As an example, in some embodiments, the IoT module 138 includes a machine learning device identification engine that uses a feed-forward neural network for multi-class classification. It supports both supervised learning for profile-level device identification and unsupervised learning to classify devices into different categories for further study. For supervised learning, labeled data (i.e., known profiles of devices and their corresponding features) are provided to train the model. The model then predicts the profile of new devices based on the features (including 256 features corresponding to each byte frequency percentage). The following are examples of additional features that can be extracted from the network traffic metadata and included in the modeling: total byte count, total packet count, total session count, total session time, server port number, application list, encrypted byte count, remote IP list, download payload byte count, HTTP request count, HTTP response count, TCP SYN count, and TCP ACK count. For unsupervised learning, devices are classified into a category with an unknown profile based on their features. If further research reveals profile-level identity of devices within a category, that information can be used to identify all devices within the same category.

[0063] Finally, at 706, the classification determined at 704 is provided to a security appliance configured to apply policies to the IoT device. As discussed above, this allows very fine-grained security policies to be implemented in potentially mission-critical environments with minimal administrative effort. If applicable, security platform 140 can recommend specific policies based on the classification determined at 704. The following are examples of policies that may be implemented:

[0064] *Deny internet traffic to all infusion pumps (regardless of vendor).

[0065] * Deny all GE ECG machine internet traffic except to and from designated GE hosts.

[0066] *Allow only internal traffic to Picture Archiving and Communication System (PACS) servers for all CT scanners (regardless of vendor).

[0067] Although the above embodiments have been described in some detail for clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims

1. 1. A system including a processor and a memory, The processor, Obtaining byte frequency information from an application executing on an Internet of Things (IoT) device having a corresponding observed flow; transmitting the obtained byte frequency information to a remote system; receiving a classification of the application from the remote system; applying a policy to the IoT device based at least in part on the received classification; It is structured as follows: the memory is coupled to the processor and configured to provide instructions to the processor; system.

2. the byte frequency information includes a byte flow distribution; The system of claim 1 .

3. The system of claim 1 , wherein the remote system is configured to determine a byte flow distribution using the received byte frequency information.

4. The classification is determined at least in part based on a threshold match. The system of claim 1 .

5. The byte frequency information is determined to be within a threshold of byte frequency information associated with an existing byte frequency profile; and and wherein the remote system is configured to categorize the IoT device along with other devices associated with the profile. The system of claim 4.

6. the byte frequency information is determined to be outside a byte frequency information threshold range associated with one or more existing byte frequency profiles; and In response, the remote system is configured to generate a new profile. The system of claim 4.

7. The threshold match is based, at least in part, on a plurality of features. The system of claim 4.

8. The classification is determined, at least in part, based on a model. The system of claim 1 .

9. The model is trained using a set of features that includes at least a portion of the byte flow distribution information. The system of claim 8.

10. the byte frequency information is determined, at least in part, based on a predefined number of packets in a flow. The system of claim 1 .

11. the byte frequency information is determined using a transport layer payload. The system of claim 1 .

12. 1. A method comprising: obtaining byte frequency information from an application executing on an Internet of Things (IoT) device having a corresponding observed flow; transmitting the obtained byte frequency information to a remote system; receiving a classification of the application from the remote system; applying a policy to the IoT device based at least in part on the received classification; A method comprising:

13. A computer program stored on a tangible computer readable storage medium and comprising a plurality of computer instructions, The instructions, when executed by a processor of a computer, cause the computer to: obtaining byte frequency information from an application executing on an Internet of Things (IoT) device having a corresponding observed flow; transmitting the obtained byte frequency information to a remote system; receiving a classification of the application from the remote system; applying a policy to the IoT device based at least in part on the received classification; A computer program that causes the

Images