IoT Device Identification via Packet Flow Behavior Machine Learning Models

Abstract

A method for identifying Internet of Things (IoT) devices, including packet flow behaviors, is disclosed by using machine learning models. Information associated with network communication of an IoT device is received. A determination is made as to whether the IoT device has been previously classified. In response to the determination that the IoT device has not been previously classified, a determination is made that the probability match of the IoT device for a behavior signature exceeds a threshold. Based at least partially on the probability match, the classification of the IoT device is provided to a security appliance configured to apply a policy to the IoT device.

Description

Technology Field

[0001] The present invention relates to the identification of IoT devices through a packet flow behavior machine learning model. Background Technology

[0002] Malicious individuals attempt to compromise computer systems through various methods. For example, they may embed or include malicious software ("malware") in email attachments and transmit or cause unsuspecting users to receive it. Once executed, the malware can damage the victim's computer and perform additional malicious actions (such as extracting sensitive data or spreading to other systems). Computers can be hardened against these and other breaches using various approaches. Unfortunately, existing approaches to protecting computers are not necessarily suitable for all computing environments. Furthermore, malware creators are constantly adapting their techniques to evade detection, and there is a continuous need for improved technologies to detect malware and prevent damage in various situations.

[0003] The present invention may be embodied in various ways, including a process; a device; a system; a composition of materials; a computer program product embodied in a computer-readable storage medium; and / or a processor, such as a processor configured to execute instructions stored in memory coupled to the processor and / or provided by it. In this specification, such implementations or all other forms that the present invention may take may be referred to as techniques. Generally, the order of steps of the disclosed processes may be changed within the scope of the present invention. Unless otherwise specified, components such as a processor or memory described as configured to perform a task may be embodied as general components temporarily configured to perform a task at a given time or specific components manufactured to perform a task. As used herein, the term 'processor' means one or more devices, circuits and / or processing cores configured to process data such as computer program instructions.

[0004] A detailed description of one or more embodiments of the present invention is provided below, together with the accompanying drawings illustrating the principles of the invention. Although the invention is described in relation to these embodiments, the invention is not limited to any of the embodiments. The scope of the invention is limited only by the claims, and the invention includes numerous alternatives, modifications, and equivalents. To provide a complete understanding of the invention, many specific details are described in the following description. These details are provided for illustrative purposes, and the invention may be practiced according to the claims without some or all of these specific details. For clarity, technical data known in the art related to the invention has not been described in detail, so as not to make the invention unnecessarily obscure.

[0005] I. Overview

[0006] A firewall generally protects a network from unauthorized access while allowing authorized communications to pass through it. A firewall is typically a device, a 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 devices (e.g., computers, smartphones, or other types of network-enabled devices). Firewalls can also be integrated or run as one or more software applications on various types of devices, such as computer servers, gateways, network / routing devices (e.g., network routers), and data appliances (e.g., security appliances or other types of special-purpose devices), and in various implementations, specific behaviors may be implemented on special-purpose hardware such as ASICs or FPGAs.

[0007] Firewalls generally deny or allow network transmissions based on a set of rules. These sets of rules are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching protected devices. 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 may be specified in firewall rules or policies that can be triggered according to various criteria, such as those described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0008] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) may include various security functions (e.g., firewalls, anti-malware, intrusion prevention / detection, Data Loss Prevention (DLP), and / or other security functions), networking functions (e.g., routing, Quality of Service (QoS), workload balancing of network-related resources, and / or other networking functions), and / or other functions. For example, routing functions may be based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

[0009] Basic packet filtering firewalls filter network communication traffic by inspecting individual packets transmitted through the network (e.g., stateless packet filtering firewalls, such as packet filtering firewalls or first-generation firewalls). Stateless packet filtering firewalls generally inspect the individual packets themselves and apply rules based on the inspected packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port numbers).

[0010] 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 specific applications and protocols (e.g., web browsing using HTTP (HyperText Transfer Protocol), DNS (Domain Name System) requests, file transfer using FTP (File Transfer Protocol), and various other types of applications and protocols such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, application firewalls can block unauthorized protocols attempting to communicate through standard ports (e.g., unauthorized / out-of-policy protocols attempting to penetrate using non-standard ports for a given protocol can generally be identified using application firewalls).

[0011] Stateful firewalls can also perform state-based packet inspection, where each packet is examined within a series of packet contexts associated with the packet flow of network transmission. This firewall technology is generally referred to as state-based packet inspection because it maintains 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 a faulty connection. For example, the state of a connection can itself serve as one of the criteria that trigger rules within a policy.

[0012] 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 technologies. For example, certain modern 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 are expanding the list of applications that these firewalls can automatically identify to thousands of applications. Examples of these next-generation firewalls may be commercially available from Palo Alto Networks, Inc. (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 various identification technologies such as: APP-ID for precise application identification; User-ID for user identification (e.g., by user or user group); Content-ID for real-time content scanning (e.g., controlling web surfing and restricting data and file transfers); and Device-ID (e.g., for identifying IoT device types). These identification technologies allow enterprises to securely use applications by utilizing business-related concepts, rather than following the traditional approaches provided by existing port-blocking firewalls. Furthermore, special-purpose hardware for next-generation firewalls (e.g., implemented as dedicated appliances) is typically general-purpose hardware (e.g., Palo Alto Networks, Inc., which uses dedicated function-specific processing tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).It provides a higher level of performance for application inspection than software running on security appliances provided by.

[0013] Advanced or next-generation firewalls can also be implemented using virtualized firewalls. Examples of these next-generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks’ VM series firewalls supporting various commercial virtualization environments including VMware® ESXi™ and NSX™, Citrix® Netscaler SDX™, KVM / OpenStack (Centos / RHEL, Ubuntu®), and Amazon Web Services (AWS)). For example, virtualized firewalls can support similar or exactly the same next-generation firewall and advanced threat protection features available in physical form factor appliances, enabling enterprises to securely enable applications flowing into private, public, and hybrid cloud computing environments. Through automation features such as VM monitoring, dynamic address groups, and REST-based APIs, enterprises can proactively monitor VM changes to dynamically feed their context into security policies, thereby eliminating policy lag that can occur when VMs change. Brief explanation of the drawing

[0014] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. Figure 1 illustrates an example of an environment where malicious activity is detected and the damage is reduced. FIG. 2a illustrates an example of a data appliance. FIG. 2b is a functional diagram of the logical components of an embodiment of a data appliance. Figure 2c illustrates an exemplary event path between an IoT server and an IoT module. Figure 2d illustrates an example of a device search event. Figure 2e illustrates an example of a session event. Figure 2f illustrates an example of an IoT module. FIG. 2g illustrates an exemplary method for implementing IoT device analysis. FIG. 3 illustrates an example of a process for passively providing AAA support for IoT devices in a network. FIGS. 4a through 4c illustrate examples of RADIUS messages transmitted by an IoT server to an AAA server on behalf of an IoT device in various embodiments. Figure 5 illustrates an example of an IoT module. Figure 6 illustrates an example of a process for classifying IoT devices. Figures 7a and 7b illustrate examples of firewall rules. FIGS. 8 through 10 illustrate parts of exemplary interfaces. Figure 11 illustrates an example of a process for generating a policy to be applied to communication involving an IoT device. Figure 12 illustrates a sequence of arrival times between packets. Figure 13a illustrates the training data. Figure 13b shows the results of training a model using the data set shown in Figure 13a. FIG. 14a illustrates two examples of devices that match the device behavior signature. FIG. 14b illustrates two examples of devices that do not match the device behavior signature. Figure 15 illustrates an example of a process for classifying IoT devices. Specific details for implementing the invention

[0015] II. Exemplary Environment

[0016] FIG. 1 illustrates an example of an environment in which malicious activity is detected and its damage is reduced. In the example illustrated in FIG. 1, client devices (104-108) are laptop computers, desktop computers, and tablets located in the corporate network (110) of a hospital (also referred to as "Acme Hospital"). A data appliance (102) is configured to enforce policies regarding communication between client devices, such as client devices (104, 106), and nodes outside the corporate network (110) (e.g., accessible via an external network (118)).

[0017] Examples of these policies include managing traffic formation, quality of service, and traffic routing. Other examples of policies include security policies such as requiring scanning for threats in incoming (and / or outgoing) email attachments, website content, files exchanged via instant messaging programs, and / or other file transfers. In some embodiments, the data appliance (102) is also configured to enforce policies on traffic remaining within the enterprise network (110).

[0018] The network (110) also includes a directory service (154) and an Authentication, Authorization, and Accounting (AAA) server (156). In the example illustrated in FIG. 1, the directory service (154) (also referred to as an identity provider or domain controller) uses Lightweight Directory Access Protocol (LDAP) or other suitable protocols. The directory service (154) is configured to manage user IDs and credential information. An example of the directory service (154) is a Microsoft Active Directory server. Other types of systems may also be used instead of an Active Directory server, such as a Kerberos-based system, and the technologies described herein are adapted accordingly. In the example illustrated in FIG. 1, the AAA server (156) is a network admission control (NAC) server. The AAA server (156) is configured to authenticate wired, wireless, and VPN users and devices to the network, evaluate and modify devices for policy compliance before allowing access to the network, differentiate access based on roles, and audit and report on users in the network. An example of an AAA server (156) is a Cisco Identity Services Engine (ISE) server using Remote Authentication Dial-In User Service (RADIUS). Other types of AAA servers, including those using protocols other than RADIUS, may be used with the technologies described herein.

[0019] In various embodiments, the data appliance (102) is configured to listen to communication with the directory service (154) and / or the AAA server (156) (e.g., passively monitoring messages). In various embodiments, the data appliance (102) is configured to communicate with the directory service (154) and / or the AAA server (156) (i.e., actively communicating messages with them). In various embodiments, the data appliance (102) is configured to communicate with an orchestrator (not shown) that communicates with various network elements such as the directory service (154) and / or the AAA server (156) (e.g., actively communicating messages with them). Other types of servers may also be included in the network (110) and, where applicable, may communicate with the data appliance (102), and in various embodiments, the directory service (154) and / or the AAA server (156) may also be omitted from the network (110).

[0020] Although FIG. 1 is illustrated as having a single data appliance (102), a given network environment (e.g., network (110)) may include embodiments of multiple data appliances, whether they operate individually or in cooperation. Similarly, while the term “network” is generally referred to as a single form in this specification for simplicity (e.g., “network (110)”), the technologies described in this specification may be used in various network environments of various sizes and topologies, including various mixes of networking technologies (e.g., virtual and physical) using various networking protocols (e.g., TCP and UDP) and infrastructure (e.g., switches and routers) across various network layers where applicable.

[0021] The data appliance (102) may be configured to operate in cooperation with the remote security platform (140). The security platform (140) may provide various services, including performing static and dynamic analysis of malware samples (e.g., via the sample analysis module (124)) and providing a list of signatures of known malware files, domains, etc., to data appliances such as the data appliance (102) as part of a subscription. As described in more detail below, the security platform (140) may also provide information related to the discovery, classification, management, etc. of IoT devices existing within a network such as the network (110) (e.g., via the IoT module (138)). In various embodiments, signatures, analysis results, and / or additional information (e.g., regarding samples, applications, domains, etc.) are stored in the database (160). In various embodiments, the security platform (140) comprises one or more commercially available dedicated hardware servers running typical server-class operating systems (e.g., Linux) (e.g., having multi-core processor(s), 32G+ RAM, Gigabit network interface adapter(s), and hard drive(s). The security platform (140) may be implemented across a scalable infrastructure comprising a number of such servers, solid-state drives or other storage (158), and / or other applicable high-performance hardware. The security platform (140) may comprise several distributed components, including components provided by one or more third parties. For example, part or all of the security platform (140) may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3).Additionally, whenever the security platform (140) is referred to as performing tasks such as data storage or data processing, as in the data appliance (102), it should be understood that sub-components or multiple sub-components of the security platform (140) may cooperate to perform said tasks (individually or in cooperation with third-party components). For example, the security platform (140) may cooperate with one or more virtual machine (VM) servers to perform static / dynamic analysis (e.g., via the sample analysis module (124)) and / or IoT device functions (e.g., via the IoT module (138)). An example of a virtual machine server is a physical machine comprising commercially available server-class hardware (e.g., a multi-core processor, 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 managing the security platform (140), but may also be provided by a third party. As an example, the virtual machine server may rely on EC2, along with the rest of the security platform (140) provided by dedicated hardware owned by and under the control of the operator of the security platform (140).

[0022] An embodiment of a data appliance is illustrated in FIG. 2a. The illustrated example is a representation of the physical components included in the data appliance (102) in various embodiments. Specifically, the data appliance (102) includes a high-performance multi-core central processing unit (CPU) (202) and random access memory (RAM) (204). The data appliance (102) also includes storage (210) (such as one or more hard disks or solid-state storage units). In various embodiments, the data appliance (102) stores information (RAM (204), storage (210), and / or any other suitable location) used to monitor the enterprise network (110) and implement the disclosed technologies. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policies and other configuration information, signatures, host name / URL categorization information, malware profiles, machine learning models, IoT device classification information, etc. The data appliance (102) may also include one or more optional hardware accelerators. For example, the data appliance (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, act as network processors, and / or perform other tasks.

[0023] The functions described herein as being performed by the data appliance (102) may be provided / implemented in various ways. For example, the data appliance (102) may be a dedicated device or a set of devices. A given network environment may include multiple data appliances, each of which may be configured to provide services to specific parts or sections of the network and may cooperate to provide services to specific parts or sections of the network. The functions provided by the data appliance (102) may also be executed or integrated as software on a general-purpose computer, computer server, gateway, and / or network / routing device. In some embodiments, at least some of the functions described as being provided by the data appliance (102) are instead (or additionally) provided to the client device (e.g., client device (104) or client device (106)) by software running on the client device. Functions described herein as being performed by the data appliance (102) may also be performed at least partially by the security platform (140) or in cooperation with it, and / or functions described herein as being performed by the security platform (140) may also be performed at least partially by the data appliance (102) or in cooperation with it, where applicable. As an example, various functions described as being performed by the IoT module (138) may be performed by embodiments of the IoT server (134).

[0024] Whenever the data appliance (102) is described as performing a task, a single component, a subset of components, or all components of the data appliance (102) may cooperate to perform the task. Similarly, whenever a component of the data appliance (102) is described as performing a task, a sub-component may perform the task and / or that component may perform the task in combination with other components. In various embodiments, parts of the data appliance (102) are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data appliance (102), various logical components and / or features of the data appliance (102) may be omitted, and the techniques described herein may be adapted accordingly. Similarly, additional logical components / features may be included in embodiments of the data appliance (102) where applicable. In various embodiments, one example of a component included in the data appliance (102) 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 can determine the type of traffic involved in a session, such as web browsing - social networking; web browsing - news; SSH; etc. Another example of a component included in the data appliance (102) in various embodiments is an IoT server (134), which is described in more detail below. The IoT server (134) can take various forms, including a standalone server (or set of servers), whether physical or virtualized, and can also be deployed with and / or integrated with the data appliance (102) where applicable (e.g., as illustrated in FIG. 1).

[0025] FIG. 2b is a functional diagram of the logical components of an embodiment of a data appliance. The illustrated example is a representation of the logical components that may be included in the data appliance (102) in various embodiments. Unless otherwise specified, the various logical components of the data appliance (102) may be implemented in various ways, generally including a set of one or more scripts (e.g., written in Java, Python, etc., where applicable).

[0026] As described, the data appliance (102) includes a firewall, a management plane (212), and a data plane (214). The management plane manages user interactions, such as configuring policies and providing a user interface to view log data. The data plane manages data, such as performing packet processing and session handling.

[0027] A network processor (216) is configured to receive packets from client devices, such as a client device (108), and provide them to a data plane (214) for processing. Whenever the flow module (218) identifies packets as part of a new session, a new session flow is created. Subsequent packets are identified as belonging to the session based on a flow lookup. Where applicable, SSL decryption is applied by an SSL decryption engine (220). Otherwise, processing by the SSL decryption engine (220) is omitted. The decryption engine (220) can help the data appliance (102) inspect and control SSL / TLS and SSH encrypted traffic, and thus help block threats that may be hidden in the encrypted traffic. The decryption engine (220) can also help prevent sensitive content from leaving the corporate network (110). Decryption can be selectively controlled (e.g., enabled or disabled) based on the following parameters: URL category, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., specifying sessions to decrypt), decryption profiles can be assigned to control various options for sessions controlled by the policy. For example, the use of specific cipher suites and encryption protocol versions may be required.

[0028] The application identification (APP-ID) engine (222) is configured to determine the type of traffic involved in the session. For 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 in a web browsing session, the identified application may change, and such change is recorded by the data appliance (102). For example, the user may first search for a corporate Wiki (classified as "Web Browsing - Productivity" based on the visited URL) and then search for a social networking site (classified as "Web Browsing - Social Networking" based on the visited URL). Protocols of different types have corresponding decoders.

[0029] Based on a decision made by the application identification engine (222), packets are sent to a suitable decoder configured by the threat engine (224) to combine 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 should happen to the packets. If necessary, the SSL encryption engine (226) can re-encrypt the decrypted data. The packets are forwarded using a forward module (228) to be transmitted (e.g., to a destination).

[0030] As also illustrated in FIG. 2b, policies (232) are received and stored in the management plane (212). The policies may include one or more rules that can be specified using domain and / or host / server names, and the rules may apply one or more signatures or other matching criteria or heuristics, such as for security policy enforcement on subscriber / IP flows based on various parameters / information extracted from monitored session traffic flows. An interface (I / F) communicator (230) is provided for management communication (e.g., via (REST) ​​API, messages, or network protocol communication or other communication mechanisms). The policies (232) may also include policies for managing communications involving IoT devices.

[0031] III. IoT Device Discovery and Identification

[0032] Returning to FIG. 1, assume that a malicious individual has created malware (130) (e.g., using the system (120)). The malicious individual wants vulnerable client devices to execute a copy of the malware (130), thereby compromising the client devices and causing the client devices to become bots in a botnet. The compromised client devices can then be instructed to perform tasks (e.g., cryptocurrency mining, participating in denial-of-service attacks, propagating to other vulnerable client devices), report information, or leak data to an external entity (e.g., a command and control (C&C) server (150)), as well as, where applicable, receive commands from the C&C server (150).

[0033] Some of the client devices illustrated in FIG. 1 are commercial computing devices typically used within corporate organizations. For example, the client devices (104, 106, 108) each run a common operating system (e.g., macOS, Windows, Linux, Android, etc.). These commercial computing devices are often provisioned and maintained by administrators (e.g., company-issued laptops, desktops, and tablets, respectively) and operate with user accounts (managed by a directory service provider (also referred to as a domain controller) consisting of, for example, user IDs and credential information). For example, an employee named Alice may be issued a laptop (104) that she uses to access her ACME-related emails and perform various ACME-related tasks. Other types of client devices (generally referred to as Internet of Things or IoT devices) are also increasingly present on networks and are often "unmanaged" by IT departments. Some of these devices (e.g., remote conferencing devices) can be found in various different types of enterprises (e.g., IoT whiteboards (144 and 146)). These devices may also be vertically specific. For example, infusion pumps and computed tomography scanners (e.g., CT scanner (112)) are examples of IoT devices that can be found within a medical enterprise network (e.g., network (110)), and robotic arms are examples of devices that can be found in a manufacturing enterprise network. Additionally, consumer-oriented IoT devices (e.g., cameras) may also exist in enterprise networks. Like commercial computing devices, IoT devices within a network can communicate with resources located inside or outside of these networks (or both, if applicable).

[0034] Like general-purpose computing devices, IoT devices are targets for malicious individuals. Unfortunately, the presence of IoT devices within a network can present several unique security and management challenges. IoT devices are often low-power or special-purpose devices and are frequently used without the knowledge of network administrators. Even when such administrators are aware, they may be unable to install endpoint protection software or agents on the IoT devices. IoT devices may be managed by and communicate exclusively or directly with third-party cloud infrastructure (e.g., industrial thermometers (152) communicating directly with cloud infrastructure (126)) using proprietary (or non-standard) protocols. This can confuse attempts to monitor network traffic inside and outside such devices to determine when a threat or attack is occurring against the device. Additionally, some IoT devices are mission-critical (e.g., network-connected surgical systems) (e.g., in a medical environment). Unfortunately, damage to IoT devices (e.g., by malware (130)) or the incorrect application of security policies to traffic associated with IoT devices can have potentially fatal effects. By using the techniques described herein, the security of networks consisting of various types of IoT devices can be improved, and damage to these networks can be reduced.

[0035] In various embodiments, the data appliance (102) includes an IoT server (134). In some embodiments, the IoT server (134) is configured to identify IoT devices within a network (e.g., network (110)) in cooperation with the IoT module (138) of the security platform (140). Such identification can be used, for example, by the data appliance (102), to help create and enforce policies regarding traffic associated with IoT devices and to enhance the functionality of other elements of the network (110) (e.g., providing context information to AAA (156)). In various embodiments, the IoT server (134) incorporates one or more network sensors configured to passively sniff / monitor traffic. One exemplary method of providing such network sensor functionality is a tap interface or a switch mirror port. If applicable, other approaches to traffic monitoring may be applied (additionally or instead).

[0036] In various embodiments, the IoT server (134) is configured to provide logs or other data (e.g., collected from a passive monitoring network (110)) to the IoT module (138) (e.g., via a frontend (142)). FIG. 2c illustrates an exemplary event path between the IoT server and the IoT module. The IoT server (134) transmits device discovery events and session events to the IoT module (138). Exemplary discovery events and session events are illustrated in FIG. 2d and FIG. 2e, respectively. In various embodiments, whenever a packet capable of uniquely identifying or verifying the ID of a device is observed (e.g., whenever a DHCP, UPNP, or SMB packet is observed), a discovery event is transmitted by the IoT server (134). Each session held by the device (including other nodes inside or outside the device's network) is described within a session event that summarizes information about the session (e.g., source / destination information, number of received / transmitted packets, etc.). Where applicable, multiple session events may be batched together by the IoT server (134) before being transmitted to the IoT module (138). In the example illustrated in FIG. 2e, two sessions are included. The IoT module (138) provides device classification information to the IoT server (134) through device determination events (234).

[0037] One exemplary method of implementing the IoT module (138) is to use a microservices-based architecture. The IoT module (138) may also be implemented using other programming languages, databases, hardware, and software environments where applicable, and / or may be implemented as services that are messaging-enabled, context-bound, autonomously developed, independently usable, decentralized, and built and released by automated processes. One task performed by the IoT module (138) is to identify IoT devices from data provided by the IoT server (134) (and provided by other embodiments of data appliances such as data appliances (136 and 148)) and to provide additional context information about these devices (e.g., again to their respective data appliances).

[0038] FIG. 2f illustrates an embodiment of an IoT module. Area (295) represents a set of Spark applications running at intervals (e.g., every 5 minutes, every hour, every day) across data from all tenants. Area (297) represents a Kafka message bus. Session event messages received by the IoT module (138) (e.g., from the IoT server (134)) bundle multiple events together as observed at the IoT server (134) (e.g., to conserve bandwidth). A transformation module (236) is configured to flatten the received session events into individual events and publish them in 250. The flattened events are aggregated by an aggregation module (238) using various different aggregation rules. An example of a rule is "aggregate all event data for a specific device and each (APP-ID) application used during a time interval (e.g., 5 minutes)." Another example of a rule is “aggregate all event data for a specific device communicating with a specific destination IP address during a time interval (e.g., 1 hour).” For each rule, the aggregation engine (238) tracks a list of attributes to be aggregated (e.g., a list of applications used by the device or a list of destination IP addresses). A feature extraction module (240) extracts features (252) from the attributes.The analysis module (242) uses extracted features to perform device classification (e.g., using supervised and unsupervised learning), and the results (254) are used to perform other types of analyses (e.g., through the operational intelligence module (244), the threat analysis module (246), and the anomaly detection module (248). The operational intelligence module (244) provides analyses related to the OT framework and operational or business intelligence (e.g., how the device is used). Alerts (256) may be generated based on the results of the analyses. In various embodiments, MongoDB (258) is used to store aggregated data and feature values. Background services (262) receive data aggregated by Spark applications and write the data to MongoDB (258). The API server (260) retrieves and merges data from MongoDB (258) to process requests received from the Front End (142).

[0039] FIG. 2g illustrates an exemplary method for implementing IoT device identification analyses (e.g., within an analysis module (242) and, as an example of related elements, within an IoT module (138)). Search events and session events (e.g., illustrated in FIG. 2d and 2e, respectively) are received as raw data (264) on a message bus as Kafka topics (also stored in storage (158)). Features are extracted by a feature engine (276) (e.g., which can be implemented using Spark / MapReducer). The raw data is enhanced with additional context information by a security platform (140), such as geographic location information (e.g., source / destination addresses) (266). During metadata feature extraction (268), the number of packets transmitted from an IP address within a certain time interval, the number of applications used by a specific device during the time interval, and the number of IP addresses contacted by the device during the time interval are configured. Features are transmitted in real time to an inline analysis engine (272) (e.g., in JSON format) (e.g., on a message bus) and stored for subsequent querying (e.g., during offline modeling (299)) in a suitable format (e.g., Apache Parquet / DataFrame) in a feature database (270).

[0040] In addition to features built from metadata, a second type of feature, referred to herein as analysis features, can be built by the IoT module (138) (274). An exemplary analysis feature is built over time based on time-series data using aggregated data. The analysis features are similarly transmitted to the analysis engine (272) in real time and stored in the feature database (270).

[0041] The inline analysis engine (272) receives features on the message bus through a message handler. One task performed is activity classification (278), which attempts to identify activities associated with the session (e.g., file download, login / authentication process, or disk backup activity) based on the received feature values / session information and attaches applicable tags. One way to implement activity classification (278) is through a neural network-based multi-layer perceptron combined with a convolutional neural network.

[0042] It is assumed that, as a result of activity classification, a specific device is determined to engage in printing activities (e.g., using a printing protocol) and also periodically contact HP-owned resources (e.g., to check for updates by calling an HP URL and using it to report status information). In various embodiments, classification information is passed to both a clustering process (unsupervised) and a prediction process (supervised). If one of the processes results in successful classification of the device, the classification is stored in the device database (286).

[0043] Devices can be clustered into multiple clusters by a first-stage clustering engine (280) based on their attributes and other behavioral patterns (e.g., acting like a printer, acting like an HP device, etc.). One way to implement the clustering engine (280) is to use an extreme gradient boosting framework (e.g., XGB). The first-stage classifier can be useful for classifying devices that are similar to existing known devices but have not been previously seen (e.g., a new thermostat vendor starts selling thermostat devices that operate similarly to known thermostats).

[0044] As illustrated in FIG. 2g, activity classification information is also provided to a set of classifiers (282), and prediction is performed based on the features provided for the device. Two possibilities may occur. In the first scenario, it is determined that the device is highly likely to match a known device profile (i.e., a high confidence score). If so, information about the device is provided to a second-stage classifier (284) that makes a final determination on the identification of the device (e.g., using the provided information and any additional applicable context 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, it is assumed 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 classifier (282) may be provided to the clustering engine (280) as additional information available for clustering.

[0045] Additionally, an offline modeling module (299) is illustrated in FIG. 2g. The offline modeling module (299) is contrasted with the inline analysis engine (272) because it has no time constraints (the inline analysis engine (272) attempts to provide device classification information in real time (e.g., as a message (234)). Periodically (e.g., once a day or once a week), the offline modeling module (299) (e.g., implemented using Python) rebuilds the models used by the inline analysis module (272). The activity modeling engine (288) builds models for the activity classifier (278) that are also used for the device type models (296) used by classifiers for device identification during inline analysis. The baseline modeling engine (290) builds baseline behavior models for the device models that are also used when modeling specific types of device anomalies (292), such as a kill chain, and specific types of threats (294). In various embodiments, the generated models are stored in a model database (298).

[0046] IV. Network Entity ID AAA

[0047] As previously mentioned, assume that Alice has been issued a laptop (104) from ACME. Various components of the network (110) will cooperate to authenticate Alice's laptop when Alice uses the laptop to access various resources. For example, when Alice connects the laptop (104) to a wireless access point located within the network (110) (not shown), the wireless access point may communicate (directly or indirectly) with the AAA server (156) while provisioning network access. As another example, when Alice uses the laptop (104) to access her ACME email, the laptop (104) may communicate (directly or indirectly) with the directory service (154) while retrieving her inbox, etc. As a commercial laptop running a commercial operating system, the laptop (104) can generate appropriate AAA messages (e.g., RADIUS client messages) that help the laptop (104) access the appropriate resources it needs.

[0048] As previously mentioned, one problem raised 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, or managed by network administrators), do not support protocols such as RADIUS, and therefore cannot be integrated with AAA services such as other devices such as laptops (104). Various approaches, each with its own disadvantages, may be adopted to provide network access within the network (110) to IoT devices. One option is to restrict IoT devices from using the guest network to the ACME (e.g., via a pre-shared key). Unfortunately, this can limit the utility of the IoT device if it cannot communicate with other nodes within the network (110) that it needs to access legally. Another option is to allow IoT devices unrestricted access to the network (110), which mitigates the security benefits of having a segmented network. Another option is to manually specify rules for ACME that control how a given IoT device should be able to access the resources of the network (110). This approach is generally not maintainable or implementable for various reasons. For example, administrators may not often be involved in the deployment of IoT devices and therefore will not know whether policies for such devices should be included (e.g., in the data appliance (102)).For example, even if administrators can manually configure policies for specific IoT devices of the appliance (102) (e.g., devices such as device (112)), keeping these policies up to date is prone to errors and generally cannot be maintained given the number of IoT devices that may exist in the network (110). Furthermore, such policies are likely to be simple (e.g., assigning the CT scanner (112) to a specific network by IP address and / or MAC address) and do not allow for finer control over connections / policies related to the CT scanner (112) (e.g., dynamically including policies applicable to POS terminals (point of sales terminals) and surgical devices). Additionally, as previously mentioned, even when the CT scanner (112) is manually included in the data appliance (102), IoT devices generally do not support technologies such as RADIUS, and the benefits of such AAA servers managing networking access of the CT scanner (112) will be limited compared to other types of devices (e.g., laptops (104)) that more fully support such technologies. As described in more detail below, in various embodiments, the data appliance (102) is configured to provide support for AAA functions to IoT devices present in the network (110) in a manual manner (e.g., via the IoT server (134)).

[0049] In the following discussion, it is assumed that ACME’s Alice department has recently purchased an interactive whiteboard (146) and thus Alice is able to collaborate with other ACME employees and outsiders (e.g., Bob, a researcher at Beta University who has his own network (114), data appliance (136), and whiteboard (144). As part of the initial setup of the whiteboard (146), Alice connects the whiteboard to a power source and provides the whiteboard with a wired connection (e.g., to an outlet in a conference room) or wireless credentials (e.g., credentials for use by visitors to the conference room). When the whiteboard (146) is provisioned with a network connection, the IoT server (134) will recognize the whiteboard (146) as a new device within the network (110) (e.g., through a mechanism such as the network sensor described above). One action taken in response to such detection is to communicate with the security platform (140) (e.g., creating a new record for the whiteboard (146) in the database (160) and retrieving currently available context information associated with the whiteboard (146) (e.g., obtaining the manufacturer of the whiteboard (146), the model of the whiteboard (146), etc.). Any context information provided by the security platform (140) may be provided to the data appliance (102) (and stored therein), and, where applicable, may be provided to the directory service (154) and / or the AAA server (156). Where applicable, the IoT module (138) may provide updated context information for the whiteboard (146) when it becomes available to the data appliance (102). And, the data appliance (102) may similarly provide continuous information about the whiteboard (146) to the security platform (140) (e.g., via the IoT server (134)).Examples of such information include observations (e.g., statistical information on connections being made) regarding the behavior of the whiteboard (146) in the network (110) that can be used by the security platform (140) to build behavioral profiles for devices such as the whiteboard (146). Similar behavioral profiles may be built by the security platform (140) for other devices (e.g., the whiteboard (144)). These profiles may be used for various purposes, including detecting anomalous behaviors. As an example, a data appliance (148) may use information provided by the security platform (140) to detect whether the thermometer (152) is operating abnormally compared to historical observations of the thermometer (152) and / or compared to other thermometers (not shown) including similar models, manufacturers, or more generally thermometers in other networks. When abnormal behavior is detected (e.g., by a data appliance (148)), appropriate corrective measures can be automatically taken, such as restricting access of the thermometer (152) to other nodes on the network (116) and generating an alarm.

[0050] FIG. 3 illustrates an example of a process for passively providing AAA support for an IoT device in a network. In various embodiments, the process (300) is performed by an IoT server (134). The process begins at 302 when a set of packets transmitted by the IoT device is acquired. For example, when the whiteboard (146) is first provisioned to the network (110), such packets may be passively received by the IoT server (134) at 302. The packets may also be received at 302 during subsequent use of the whiteboard (146) (e.g., because Alice has whiteboard sessions with Bob through the whiteboard (144)). At 304, at least one packet included in the set of data packets is analyzed. As an example of the processing performed at 304, the IoT server (134) determines that the packets received at 302 are being transmitted by the whiteboard (146). One action that the IoT server (134) may take is to identify the whiteboard (146) as a new IoT device on the network (110) and, if available, obtain context information from the IoT module (138). In 306, the IoT server (134) transmits an AAA message containing information associated with the IoT device on behalf of the IoT device. An example of such a message is illustrated in FIG. 4a. As previously mentioned, the whiteboard (146) does not support the RADIUS protocol. However, the IoT server (134) can generate a message as illustrated in FIG. 4a on behalf of the whiteboard (146) (e.g., using information received in 302 and, if applicable, also received from the security platform (140)).As previously mentioned, when the IoT server (134) provides information regarding the whiteboard (146) to the IoT module (138), the IoT module (138) may take various measures, such as creating a record of the whiteboard (146) in the database (160) and filling the record with context information regarding the whiteboard (146) (e.g., determining the manufacturer, model number, etc.). As additional context information regarding the whiteboard (146) is collected by the security platform (140), the profile may be updated and propagated to the data appliance (102). When the whiteboard (146) is initially provisioned within the network (110), additional context information may not be available (e.g., the security platform (140) may not have such additional information, or it may not be immediate for the security platform (140) to provide such information to the IoT server (134). Accordingly, as illustrated in FIG. 4a, a RADIUS message generated by the IoT server (134) on behalf of the whiteboard (146) may contain limited information. As additional context information is received (e.g., from the IoT module (138) by the IoT server (134)), subsequent RADIUS messages transmitted by the IoT server (134) on behalf of the whiteboard (146) may be augmented with this additional information. Examples of such subsequent messages are illustrated in FIG. 4b and 4c. FIG. 4b illustrates an example of a RADIUS message that the IoT server (134) may transmit on behalf of the whiteboard (146) as context information regarding the whiteboard (146) is provided by the IoT module (138) (e.g., including a database of context information regarding various IoT devices). In the example illustrated in FIG. 4b, context information such as the manufacturer of the whiteboard (Panasonic) and the characteristics of the device (e.g., interactive whiteboard) is included.This context information can be used by AAA servers, such as the AAA server (156), to provide AAA services to the whiteboard (146) (without needing to modify the whiteboard (146)), and, for example, to automatically provision it to a subnet dedicated to remote conferencing equipment. Other types of IoT devices can also be automatically grouped based on attributes such as device type, purpose, etc. (for example, critical surgical equipment is automatically provisioned to a subnet dedicated to that equipment and is therefore separated from other devices on the network). This context information can be used to enforce traffic shaping policies, such as a policy to prioritize whiteboard (146) packets over social networking packets (determined, for example, using the APP-ID). Granular policies can be similarly applied to communication with critical surgical equipment (for example, preventing all devices communicating with such equipment from having outdated operating systems, etc.). In the example illustrated in FIG. 4c, additional context information is included in the RADIUS message by the IoT server (134) on behalf of the whiteboard (146). This 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), it is likely that all context information illustrated in FIG. 4c is not available. As the whiteboard (146) is used within the network (110) over time (e.g., as the IoT server (134) continues to passively observe packets from the whiteboard (146) and provide information to the security platform (140)), additional context information may be collected. This additional information may be utilized to enforce granular policies (e.g., by the data appliance (102)).For example, as illustrated in FIG. 4c, the whiteboard (146) runs a specific operating system that is Linux-based and has version 3.16. Often, IoT devices run versions of operating systems that cannot be upgraded or patched. These devices can pose a security risk when exploits for those operating systems are developed. The data appliance (102) can implement security policies based on context information, such as isolating (or otherwise restricting) IoT devices with older operating systems from other nodes of the network (110), while allowing less restrictive network access to IoT devices with current operating systems.

[0051] FIGS. 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). For example, RADIUS account start messages can be triggered when traffic from the whiteboard (146) is first observed. Periodic RADIUS account intermediate update messages can be sent while the whiteboard is in use, and RADIUS account stop messages can be sent when the whiteboard (146) goes offline.

[0052] V. IoT Device Discovery and Identification

[0053] As discussed above, one task performed by the security platform (140) (e.g., via the IoT module (138)) is IoT device classification. For example, when the IoT server (134) sends a device discovery message to the IoT module (138), the IoT module (138) determines the classification of the device and attempts to respond (e.g., with the determination (234) illustrated in FIG. 2c). The device is associated with a unique identifier by the IoT module (138), and thus, if applicable, subsequent classification of the device does not need to be performed (or, if applicable, less frequently than if not). Also, as discussed above, the determined classification can be used (e.g., by the data appliance (102)) to enforce policies for traffic to / from the device.

[0054] Various approaches can be used to classify devices. The first approach performs classification based on a set of rules or heuristics that utilize static attributes of the device, such as the Organizationally Unique Identifier (OUI) appearing in the first three bytes of the Media Access Control (MAC) address and the types of applications running. The second approach performs classification using machine learning techniques that utilize dynamic but predefined attributes of the device extracted from its network traffic (e.g., the number of packets transmitted per day). Unfortunately, all of these approaches have weaknesses.

[0055] Rule-based approaches generally require separate rules to be manually generated for each type of IoT device (describe which attributes / values ​​should be used as signatures for the device's signature type). One challenge presented by this approach is determining which signatures are relevant to device identification and are unique among other device signatures. Additionally, using a rule-based approach allows for the use of a limited number of static attributes readily available from traffic (e.g., user agent, OUI, URL destination, etc.). Attributes generally need to be simple enough to be represented as patterns that can be matched by regular expressions. Another challenge lies in identifying new static attributes that exist or can identify new devices as they enter the market (e.g., a new brand or model of a CT scanner is provided). Yet another challenge is that all matching attributes from network traffic must be collected to trigger a rule. A determination cannot be reached with a smaller number of attributes. For example, a signature might require a specific device with a specific OUI to connect to a specific URL. While possessing an OUI itself may already be a sufficient indicator of a device's ID, the signature is not triggered until a URL is also observed. This can lead to a delay in determining the device's ID. Another challenge is maintaining and updating signatures as static attributes of a device that change over time (e.g., due to updates to the device or the services used by the device). For instance, a specific device may have initially been manufactured using a Type 1 network card, but over time, the manufacturer may switch to a different network card (indicating a different OUI).If rule-based systems fail to recognize changes, false positives may occur. Another challenge lies in scaling signature generation and validation as the number of new IoT devices entering the market daily approaches millions of new device instances. Consequently, newly generated rules can conflict with existing ones and lead to false positives in classification.

[0056] Machine learning-based approaches typically involve creating training models based on static and / or dynamic features extracted from network traffic. Predictions for network data from new IoT devices are based on pre-trained models that provide device IDs with associated accuracy. Examples of problems with machine learning approaches include: If predictions are performed on all new devices or devices lacking a consistent or unique ID (e.g., MAC address), the computational time required to achieve the desired accuracy may be insufficient. The number of features to be generated can be thousands or tens of thousands, and these features may be modified over a predefined time window that takes a significant amount of time (which could render policy enforcement ineffective) before a sufficient number of features for effective prediction become available. Additionally, if the goal is to minimize prediction latency, building and maintaining large-scale data pipelines to stream network data can be costly. Another issue is that noise caused by features irrelevant to a given deployment environment can reduce prediction accuracy. Also, when the number of device types reaches tens of thousands or more, there are difficulties in maintaining and updating the models.

[0057] In various embodiments, the security platform (140) addresses the problems of each of the two aforementioned approaches by using a hybrid approach to classification. In an exemplary hybrid approach, a network behavior pattern identifier (also referred to herein as a pattern ID) is generated for each type of device. In various embodiments, the pattern ID is a list of attributes or sequence features combined with their respective probabilities (as importance scores for features or behavior categories) that can be used to form distinct network behavior descriptions and identify the type of IoT device. The pattern ID can be stored (e.g., in a database) and used to identify / verify the IDs of the devices.

[0058] When training on a set of attributes, specific approaches, such as extreme gradient boosting frameworks (e.g., XGB), can provide a top list of important features (static attributes, dynamic attributes, and / or aggregated / transformed values). Once established, pattern IDs can be used to uniquely identify device types. If specific features are dominant for devices (e.g., a specific static feature (e.g., connecting to a specific URL at boot) identifies a device with 98% confidence), these can be used to automatically generate rules. Even if dominant features do not exist, representations of key features can be used as pattern IDs (e.g., when a set of multiple features is linked by a pattern). Training on a dataset containing all known models (and all known IoT devices) can avoid potential conflicts between models and unique identification features. Furthermore, pattern IDs do not need to be human-readable (although they can be stored, shared, and / or reused for identification purposes). This approach can also realize significant time savings, and thus can be used for near real-time classification. Classification of a specific device can occur as soon as a dominant feature is observed (instead of having to wait until a large number of features occur).

[0059] Examples of data that can be used to generate pattern IDs for "Teem Room Display iPad" devices may include the following (including the full list automatically generated through the training of multivariate models or multiple binary models).

[0060] * Apple devices (100%)

[0061] Special iPad (>98.5%)

[0062] * Team Room App (>95%)

[0063] * Meeting Volume Pattern VPM-17(>95%)

[0064] * Servers in the cloud (>80%)

[0065] Examples of how to implement a hybrid approach are as follows. Neural network-based machine learning systems can be used for automated pattern ID training and generation. Examples of features that can be used to train neural network models include both static features extracted from network traffic (e.g., OUI, hostname, TLS fingerprint, matching L7 payload signature, etc.) and sequential features extracted from network traffic but not specific to the environment (e.g., application, L7 attribute of the application, volume range transformed into categorical features, etc.). A lightweight data pipeline can be used to stream selected network data for real-time feature generation. A prediction engine can be used to minimize prediction latency by fetching models and providing caching. In prediction, short (e.g., minute-based) aggregation can be used to stabilize selected sequential features. Customized data normalization, enrichment, aggregation, and transformation techniques can be used to engineer the sequential features. Longer aggregation windows may be used for training to achieve better accuracy. Over time, features can be merged and aggregated to improve prediction accuracy. The backend feedback engine can be used to route the results of a "slow path" prediction system (e.g., a machine learning-based approach including a device type modeling subsystem and a device group modeling subsystem) that helps extend the attributes used for pattern ID prediction.The device group model can be drained to compensate for problems in the device type model when sufficient samples or features are not available to improve accuracy beyond an acceptable threshold (e.g., assigning prediction results based on a set of predefined types, some of which are provided with other subsystems to cluster unlabeled devices of similar types). Finally, a decision module can be used to publish the results of the real-time prediction engine.

[0066] The exemplary benefits of a hybrid approach to classification, such as the one described here, are as follows: First, rapid convergence occurs, allowing a given device to be potentially identified within minutes or seconds. Second, it addresses the individual problems of rule-based and machine learning-based systems. Third, it provides stability and consistency in prediction results. Fourth, it possesses scalability capable of supporting tens of thousands (or more) of different types of IoT devices. Prediction is generally required only for new devices (even when a given device does not have a unique ID assignment, such as L3 network traffic-based identification).

[0067] An embodiment of the module (138) is illustrated in FIG. 5. One exemplary way to implement the IoT module (138) is to use a microservices-based architecture where services are granular and protocols are lightweight. Services may also be implemented using other programming languages, databases, hardware, and software environments where applicable, and / or using relatively small services that are capable of messaging, are constrained by context, are developed autonomously, are available for independent use, are distributed, and are built and released as automated processes.

[0068] As previously mentioned, in various embodiments, the security platform (140) periodically receives information regarding IoT devices on a network (e.g., network (110)) (e.g., from a data appliance (102)). In some cases, the IoT devices may have been previously classified by the security platform (140) (e.g., a CT scanner installed on the network (110) last year). In other cases, the IoT devices will be newly identified by the security platform (140) (e.g., when the first whiteboard (146) is installed). It is assumed that a given device has not been previously classified by the security platform (140) (e.g., an entry for the device does not exist in the database (286) that stores a set of unique device identifiers and associated device information). As illustrated in FIG. 5, information regarding a new device may be provided to two different processing pipelines for classification. Pipeline (504) represents a "fast path" classification pipeline (corresponding to a pattern ID-based method), and pipeline (502) represents a "slow path" classification pipeline (corresponding to a machine learning-based method).

[0069] In the pipeline (504), fast path feature engineering is performed to identify applicable static and sequence features of the device (508). Fast path prediction is performed using pattern IDs or previously built models (e.g., models based on the most important features and built using the offline processing pipeline (506)) (510). A confidence score for the device matching a specific pattern is determined (512). If the confidence score for the device meets a pre-trained threshold (e.g., based on the overall prediction accuracy of the module (138) or its components such as 0.9), the classification can be assigned to the device (in the device database (516)) or updated if applicable. Initially, the confidence score is based on near real-time fast path processing. The advantage of this approach is that the data appliance (102) can begin applying policies to the device's traffic very quickly (e.g., within minutes of the module (138) identifying the device as new / unclassified). The appliance (102) may be configured to be fail-safe (e.g., reducing / limiting the device's ability to access various network resources) or fail-dangerous (e.g., allowing extensive access to the device) until classification judgment is made by the system (140). As additional information becomes available (e.g., through slow path processing), the reliability score may be based on such additional information where applicable (e.g., increasing the reliability score or correcting errors during fast path classification).

[0070] Examples of features that can be used (e.g., static attributes and sequence features) are as follows. Pattern IDs can be any combination of these attributes and the following logical conditions:

[0071] OUI of MAC address

[0072] Hostname string from decoded protocols

[0073] User agent strings from HTTP and other clear text protocols

[0074] System name string from decoded SNMP responses

[0075] OS, host name, domain, and user name from the decoded LDAP protocol

[0076] URLs from decoded DNS protocols

[0077] SMB versions, commands, and errors from decoded SMB protocols

[0078] TCP flags

[0079] Option strings from decoded DHCP protocols

[0080] Strings from decoded IoT protocols such as DICOM (Digital Imaging and Communications in Medicine)

[0081] List of inbound applications from the local network

[0082] List of inbound applications from the Internet

[0083] List of outbound applications for the local network

[0084] List of outbound applications for the Internet

[0085] List of inbound server ports from the local network

[0086] List of inbound server ports from the Internet

[0087] List of outbound server ports for the local network

[0088] List of outbound server ports for the Internet

[0089] List of inbound IPs from the local network

[0090] List of inbound URLs from the Internet

[0091] List of outbound IPs for the local network

[0092] List of outbound URLs for the Internet

[0093] In some cases, the confidence score determined in 512 may be very low. One reason this may occur is that the device is of a new type (e.g., a new type of IoT toy or another type of product not previously analyzed by the security platform (140)) and there is no corresponding pattern ID available for the device in the security platform (140). In this scenario, information regarding the device and classification results may be provided to an offline processing pipeline (506) capable of performing clustering (514) on behaviors indicated by the device and other applicable information (e.g., determining that the device is a wireless device, operates like a printer, uses the DICOM protocol, etc.). The clustering information may be applied as labels and flagged for applicable additional research (518), and similar devices subsequently shown are automatically grouped together. When additional information regarding a given device is determined as a result of the study (e.g., identified as corresponding to a new type of consumer-oriented IoT meat thermometer), the device (and all other devices with similar attributes) is relabeled accordingly (e.g., as a brand XYZ meat thermometer), and an associated pattern ID is generated and, if applicable, made available for use by pipelines (502 / 504) (e.g., after the models have been rebuilt). In various embodiments, offline modeling (520) is a process executed daily to train and update various models (522) used for IoT device identification. In various embodiments, the models are refreshed daily to cover newly labeled devices, and rebuilt weekly to reflect behavioral changes (for the slow path pipeline (502)) and to accommodate new features and data insights added during the week.When adding new types of devices to the security platform (140) (i.e., when creating new device patterns), it should be noted that several existing device patterns may be affected and the feature list or importance score must be updated. The process can be performed automatically (which is a major advantage over rule-based solutions).

[0094] For fast path modeling, neural network-based models (e.g., FNN) and general machine learning models (e.g., XGB) are widely used in multivariate classification models. Binary models are also constructed for selected profiles to improve results and provide input for clustering. Binary models provide yes / no responses regarding device IDs or specific device behaviors. For example, binary models can be used to determine whether a device is a type of IP phone or if there is a possibility that it is not an IP phone. Multivariate models have many outputs normalized to a probability of 1. Each output corresponds to a device type. Although binary models are generally faster, they must go through many models in the prediction process to find the correct "yes" answer for a device. Multivariate models can achieve this in a single step.

[0095] The slow path pipeline (502) is similar to the pipeline (504) in that features are extracted (524). However, the features used by the pipeline (502) generally take time to build. For example, the feature "number of bytes sent per day" requires one day to collect. As another example, certain usage patterns may take time to occur and be observed (e.g., a CT scanner is used every hour to perform a scan (first action), backs up data daily (second action), and checks the manufacturer's website for weekly updates (third action)). The slow path pipeline (502) calls a multivariate classifier (526) to attempt to classify new device instances for the entire set of features. The features used are not limited to static or sequence features, but also include volume and time-series-based features. This is generally referred to as a first-stage prediction. For certain profiles where the first-stage prediction result is not optimal (low confidence), a second-stage prediction is used in an attempt to improve the result. The slow path pipeline (502) calls a set of decision tree classifiers (528) supported by additionally obtained device contexts to classify new device instances. The additional device contexts are obtained from an external source. For example, the URL to which the device is connected may be given a risk-based reputation and category that may be included as features. As another example, the application used by the device may be given a risk-based score and category that may be included as features. By combining the results from the first-stage prediction (526) and the second-stage prediction (528), a final determination of the slow path classification can be reached with a derived confidence score.

[0096] Generally, the slow path pipeline (502) includes two stages. In the slow path pipeline, in some embodiments, the first stage models are constructed as multivariate classifiers based on neural network techniques. The second stage of the slow path pipeline is generally a set of decision-based models with additional logic to handle probability-related exceptions from the first stage. In prediction, the second stage integrates the input from the first stage, applies rules and context to validate the first stage output, and generates the final output of the slow path. The final output includes the device ID, the overall confidence score, the pattern ID that can be used in future fast path pipelines (504), and a description list. The confidence score is based on the reliability and accuracy of the model (models also have confidence scores) and the probability as part of the classification. The description list includes a list of features that contribute to the result. As mentioned above, if the result differs from the known pattern IDs, an investigation may be triggered.

[0097] In some embodiments, for slow path modeling, two types of models are constructed, one for individual IDs and the other for group IDs. For example, it is often more difficult to distinguish between two printers from different models or different vendors than to distinguish between a printer and a thermometer (for example, because printers tend to exhibit network behavior and tend to use similar protocols). In various embodiments, various printers from various vendors are included in a group, and a "printer" model is trained for group classification. The results of this group classification may provide better accuracy than a specific model for a specific printer and, where applicable, can be used to update the device's reliability score or to provide reference and validation for individual profile ID-based classification.

[0098] FIG. 6 illustrates an example of a process for classifying IoT devices. In various embodiments, the process (600) is performed by a security platform (140). The process (600) may also be performed by other applicable systems (e.g., systems deployed on-premise with IoT devices). The process (600) begins at 602 when information related to network communication of an IoT device is received. For example, this information is received by the security platform (140) when a data appliance (102) transmits a device discovery event for a given IoT device to the security platform (140). At 604, a decision is made that the device is not classified (or, if applicable, that reclassification should be performed). For example, the platform (140) may query the database (286) to determine whether the device has been classified. At 606, a two-part classification is performed. For example, the classification of the two parts is performed by the platform (140) in 606 to provide information about the device to both the fast path classification pipeline (504) and the slow path classification pipeline (502). Finally, in 608, the result of the classification process performed in 606, along with network behavior summarized from baseline modeling (290), is provided to a security appliance configured to apply policies to IoT devices. Examples of these summarized network behaviors include the most frequently used applications, URLs, and other attributes that can help form security appliance policies that can be "extracted" from baseline models trained with machine learning for IoT device profiles. As mentioned above, this enables highly granular security policies to be implemented in potentially mission-critical environments with minimal management effort.

[0099] In the first example of performing the process (600), it is assumed that an Xbox One game console is connected to the network (110). During classification, a determination may be made as to whether the device has the following dominant features: a "Vendor = Microsoft" feature with 100% confidence, a "Communicate with Microsoft Cloud Server" feature with 89.7% confidence, and a feature matching "Game Console" with 78.5% confidence. These three features / confidence scores can be matched collectively against a set of profile IDs (the process is performed by neural network-based prediction) so that the device can be identified as an Xbox One game console (i.e., a profile ID match meeting the threshold is found at 512). In the second example, it is assumed that an AudioCodes IP phone is connected to the network (110). During classification, a decision may be made as to whether the device matches the "Vendor = AudioCodes" feature with 100% confidence, the "IP audio device" feature with 98.5% confidence, and the "acting like a local server" feature with 66.5% confidence. These three features / confidence scores are also matched against a set of profile IDs, but in this scenario, it is assumed that the existing profile IDs are not matched with sufficient confidence. Then, information about the device may be provided to the clustering process (514), and if applicable, a new profile ID may ultimately be generated and associated with the device (and used to classify future devices).

[0100] Where applicable, as will be explained in more detail later, the security platform (140) may recommend specific policies based on determined classification information. The following are examples of policies that may be implemented:

[0101] Deny internet traffic to all infusion pumps (vendor-free)

[0102] Deny internet traffic to all GE ECG machines except for access from / to certain GE hosts.

[0103] * Allow only internal traffic to PACS (Picture Archiving and Communication System) servers for all CT scanners (vendor-free)

[0104] VI. Firewall IoT Security Policy

[0105] As mentioned above, IoT devices are often special-purpose devices with predefined behaviors that can be observed on a network (in contrast to general computing devices such as laptop computers). For example, regardless of the manufacturer (e.g., GE or Fujitsu), CT scanners have similar functions or exhibit similar behaviors on a network, much like other CT scanners, such as using one or more specific protocols to transmit captured patient images to a network-connected image server (e.g., via an interface) for medical personnel to examine. Other types of systems (e.g., heating, ventilation, and air conditioning (HVAC) systems) exhibit their own sets of similar and generally predefined behaviors (e.g., reporting temperature values ​​to a server once every minute via a specific protocol).

[0106] As mentioned above, by analyzing these behaviors from traffic observed (e.g., by a security platform (140)) (e.g., by a data appliance (102)), specific IoT devices can be identified (including identifying specific instances of the device, the model of the device, the manufacturer of the device, the type of the device, etc.). Additionally, the byproduct of device identification will have a device baseline model trained for classification purposes (e.g., by a baseline modeling engine (290)). Where applicable, an anomaly detection module (248) can be used to filter known anomaly behaviors when generating a baseline for a device (or a group of devices). This deep machine learning model captures the network behaviors described above. This baseline model can be used not only for device ID prediction but also for generating a general list of behavior summaries ranked according to how popular network behavior is in the device profile. One approach to behavior summarization is to use ML algorithms such as XGB to extract and rank the most contributing features (used for device identification) from the baseline model during the training process. Other approaches may also be used or combined (e.g., heuristic approaches). The most contributing features (based on confidence / confidence thresholds) essentially highlight the most common network behaviors exhibited by specific types of devices from the thousands of attributes or features used in training, and can be used for recommendations (e.g., whitelisting / blacklisting specific URLs, protocols, etc.). Behavioral summarizations may include the applications used, connections to specific network domains, payloads delivered by applications, and the volume, duration, and frequency of communication.Each attribute is assigned a frequency category such as "rare," "often," or "regular." Each attribute may also be assigned a range category such as "less than 1 MB per hour." Anomalies (e.g., damaged or malfunctioning / misconfigured IoT devices) can be detected as deviations from baselines (e.g., by a data appliance (102) working with an anomaly detection module (248)). These attributes (and known vulnerabilities to specific attacks) can be used as blueprints to automatically generate recommended firewall policies to restrict network activity associated with specific IoT devices, device types, etc. For example, regularly used applications and URLs can be used to build an "allow" firewall policy. In another example, applications not included in baseline behavior can be used to build a "deny" firewall policy. Users can adjust policies based on the frequency of network behavior summarized from hundreds of thousands of similar devices. Additionally, any known vulnerabilities (e.g., the sensitivity of a specific device to a specific attack) can be modeled separately and, where applicable, incorporated into recommended policies. An example of a key feature for a given device type is that the device checks for updates once a day at a specific URL (e.g., www.siemens.com / updates). If a threshold number of devices sharing a device type exhibit similar baseline behavior, this feature can be selected as a recommended whitelist entry for device profiles associated with that device type.

[0107] FIG. 7a illustrates a first approach for Acme to implement a set of policies related to CT scanners / image servers that may be used within a network (110). Specifically, it is assumed that Acme uses two types of CT scanners (manufactured by GE and Fujitsu). The administrator of the network (110) (hereinafter referred to as Charlie) interacts with an interface (e.g., provided by a data appliance (102) and / or a security platform (140), where applicable) and can manually specify the protocols, ports, and IP addresses that are allowed to communicate with each CT scanner and image server within the network (110). Unfortunately, this approach is time-consuming and prone to errors. For example, when a new CT scanner is added to the environment, Charlie must manually add it to the rules illustrated in FIG. 7a and potentially change or remove parts of the rules (e.g., when a new CT scanner replaces an existing scanner or when network information changes). If the total number of IoT devices in the environment is small and static IP addresses are assigned to the IoT devices, it may be possible to manually maintain rules as illustrated in Fig. 7a. However, in reality, a given environment may have hundreds or thousands of IoT devices and / or use DHCP, and manual maintenance of rules may not be possible.

[0108] Another approach is to abstract applications (e.g., "DICOM-App," representing specific protocols / ports, etc., corresponding to network traffic used for medical imaging information communication) and device types (e.g., GE-Xray-Device) according to the techniques described herein. The abstraction of the rules illustrated in FIG. 7a is illustrated in FIG. 7b. For reference, Charlie can use the extracted application types and device types without needing to provide IP addresses, ports, or protocols associated with the IoT policies. Policies such as those illustrated in FIG. 7b can be compiled and used at runtime by the data appliance (102). During compilation, based on information stored in the data appliance (102) (e.g., APP-ID information, IP information, and / or device type dictionary), the extracted elements (e.g., GE-Xray-Device) are replaced (e.g., with the IP address of each IoT device that matches the corresponding device identification).

[0109] Charlie may choose to manually create IoT device rules (e.g., using the extracts described above if desired), but may also receive policy recommendations from the security platform (140). In various embodiments, the recommendations are based on device profiles (including device type or other information) of a series of devices sharing various characteristics and baseline / general behavior (across many different customer environments / deployments). If Charlie accepts the recommended policies, appropriate rules (e.g., rules such as those illustrated in FIG. 7b) may be automatically generated (e.g., by the security platform (140)) and brought to the security appliance (102) for enforcement. The security appliance (102) learns the device profiles of IoT devices on the network and matches applicable policies to the devices as sources or targets. Where applicable, policies can be converted into formats that can be used by infrastructure types other than security appliances (102), such as network access controllers (e.g., by a security platform (140)).

[0110] In the following discussion, it is assumed that Acme has recently purchased a set of building automation devices (e.g., a set of badge readers), installed them within various Acme facilities, and brought the devices online to a part of the network (110). Using the device identification / classification techniques described above, the security platform (140) (operating with the data appliance (102)) identifies that Acme has added 28 new badge reader devices to the network and learns the various behaviors taken while those specific badge reader devices are operating within Acme's network environment (e.g., during an initial observation period of one week or one month). A portion of the management interface provided by the security platform (140) is illustrated in FIG. 8. The interface (800) indicates that Acme has a total of 65 types of IoT devices (having corresponding profiles) operating in its environment. The newly added badge readers are shown in row 802.

[0111] When Charlie clicks link 804, he is moved to the interface illustrated in FIG. 9. Area 902 indicates that the security platform (140) has identified 28 new devices as matching them with the Siemens Building Technology device profile with high reliability. Area 904 summarizes and illustrates the behavioral information collected for the 28 devices while operating within the Acme environment. Overall, the 28 devices run 8 applications within the Acme environment, communicate with 23 destinations (22 inside Acme and 1 outside), and currently have a risk score of 56. Area 906 illustrates how many of the 28 devices use each application within the Acme environment, and Area 908 illustrates whether the destinations are internal or external. Area 910 contains a comparison of the number of applications used by Siemens Building Technology devices in the Acme environment, in contrast to how these devices (sharing the same Siemens Building Technology device profile) operate in the environments of other customers of the security platform (140). As indicated in Area 910, since a typical customer deployment of Siemens Building Technology devices uses three to five applications (912), Acme's deployment falls outside the typical range (914). When Charlie hovers his cursor over Area 912, a box is displayed providing additional information about the following comparison:

[0112] Eight different applications were used by the devices in this profile. Based on data from all IoT security customers, the minimum number of applications used was 3, the average was 3, and the maximum was 5. Application usage by Siemens Building Technology devices was higher than usual. Review the application list.

[0113] Charlie can scroll further down the interface (900) to review the list of applications. As illustrated in FIG. 10, after this scroll, Charlie is reviewing the usage of "dhcp" and "bacnet" applications by badge reader devices. The "usage" designation (1002) indicates the frequency of destination profiles (e.g., "PACS server") and / or network usage patterns (device profile + application + URL (e.g., "www.siemens.com / update")) for IoT devices sharing the profile. In various embodiments, usage for each application is generated based on one month of initially collected traffic. Charlie can use the usage information when deciding whether to allow or block specific behaviors. For example, he can learn that if bacnet is not frequently used, it should be allowed only in internal domains or only in predetermined external domains (e.g., based on knowledge of Acme's environment).

[0114] When Charlie clicks area 916 of the interface (900), two options are displayed for creating a set of policies that can be applied to badge reader devices. As previously mentioned, Charlie can manually create his own set of policies for badge reader devices (e.g., by interacting with various elements of the embodiment of the interface (900). Charlie can also choose to load a recommended set of policies created by the security platform (140) using baseline / other information obtained from the environments of other customers of the security platform (140). If Charlie clicks area 916 and chooses to use a recommended set of policies (if available), the security platform (140) enumerates all available recommended sets of policies, and Charlie can download / apply them to the Acme environment and refine / adjust them to be applicable (e.g., by interacting with various functions provided by the interface (800)).

[0115] FIG. 11 illustrates an example of a process for generating a policy to be applied to communication involving an IoT device. In various embodiments, the process (1100) is performed by a security platform (140). The process (1100) may also be performed by other applicable systems (e.g., systems deployed on-premises with IoT devices). The process (1100) begins at 1102 when information related to network communication of an IoT device is received. For example, this information is received by the security platform (140) when a data appliance (102) transmits a device discovery event for a given IoT device (e.g., a badge reader device) to the security platform (140). At 1104, the received information is used to determine a device profile to be associated with the IoT device. For example, it is determined that the IoT device is a Siemens SIMATEC RF10000 device having a specific serial / MAC address, a specific IP address, etc. In this example, the determined "device type" may be "Siemens Building Technology Devices." In this section, device types (e.g., badge reader devices) and device profiles (e.g., Siemens Building Technology Devices) are generally referred to as having the same meaning. However, multiple profiles may be created for a given device type (e.g., Siemens Building Technology Devices devices located in Acme's research area and Acme's retail area), and a given profile may include multiple device types where applicable (e.g., a Siemens Building Technology Devices profile may include badge reader devices and motion trigger sensors). Finally, a recommended policy to be applied to the IoT device by the security appliance in 1106 is created.For example, instead of allowing access to all eight applications shown in FIG. 9, the security appliance (140) may recommend a policy set that allows only the three most commonly used badge reader applications (or five most commonly used badge reader applications) corresponding to the information shown in area 910. After downloading and applying the recommended policy, if Charlie needs to adjust the recommended set (e.g., add bacnet to the whitelist), he can adjust it (by interacting with the “edit” option provided by the interface (800).

[0116] VII. Identification of IoT Devices via Packet Flow Behavior Machine Learning Models

[0117] A. Introduction:

[0118] As explained above, packet inspection—such as examining packet headers and / or payloads to perform content-based pattern or signature matching—can provide useful information when attempting to identify or classify devices, such as IoT devices. This packet and content information typically includes items such as Organization Unique Identifiers (OUIs), source and destination ports, hostnames, application IDs, special destinations, user agent strings, DHCP fingerprints, and DHCP vendor class identifiers. Unfortunately, some devices can be difficult to identify through packet analysis. The following are six examples of these types of devices:

[0119] * Endpoint device where OUI information is unavailable.

[0120] Multiple types of devices sharing a single OUI (e.g., X-ray machines and ultrasound machines using wireless cards with the same OUI).

[0121] * Devices for which IDs are searchable but corresponding classification rules are difficult to define (e.g., X-ray machines that are searchable because other devices on the same subnet also have similar traffic patterns or hostnames, or because a client communicates with a server that has a name suggesting it is an X-ray machine).

[0122] Devices with encrypted traffic (which can make signature-based classification difficult).

[0123] For devices behind the network appliance (e.g., routers or switches), the device's MAC address appears as the MAC address of the router / switch interface, not the device's own MAC address.

[0124] * Devices without a hostname (existing identification rules typically use a combination of hostname and OUI as identification / classification rules).

[0125] In various embodiments, the device identification / classification techniques described above are supplemented by deploying one or more machine learning models that use packet behavior information. Examples of such packet behavior information (described in more detail below) include: packet length sequences (SPLN), packet arrival time sequences (SPIT), transport layer security (TLS) information, etc., all of which can be used as features. In various embodiments, logistic regression is used to train the dataset, and the coefficients of the logistic regression can be used as behavior signatures for the device (which can be used to identify or identify the device). Returning to FIG. 2f, in various embodiments, the training step is performed by the training module (241) using labeled events provided to the aggregation module (238) for feature extraction and training. The trained models can be stored for later use, for example, by the analysis module (242). During production / operation, events (e.g., initially provided by a data appliance (102) and processed by various components of an IoT module (138)) similarly pass through an aggregation module (238) and are transmitted to an analysis module (242), which performs device identification on the aggregated events using trained models (e.g., during inline analysis by an analysis engine (272) as an example of binary / multi-class classifiers (282)). Where applicable (e.g., when new information about new types of devices is received), the training module (241) may retrain existing models or create new models.

[0126] The techniques described herein are particularly suitable for environments where one or more data appliances (e.g., data appliances (102, 136, and 148)) exist and are used to enforce security policies, as illustrated in FIG. 1, in part because such data appliances can maintain session control blocks for each session, and session control blocks contain metadata / other information to be used by the machine learning models described herein. Additionally, if existing data appliances do not support specific feature extraction (e.g., packet length sequences, time-of-arrival sequences between packets, and / or verbose TLS information), adding these functions can be performed efficiently with minimal overhead.

[0127] B. Examples of Packet Behavior Information

[0128] The following are examples of features (associated with packet behavior parameters) that can be used to train one or more machine learning models and, for example, to identify / classify devices such as IoT devices, either individually or in combination with other models (e.g., as described above). The following exemplary features can be combined with other features, such as packet-associated metadata information (e.g., OUI, destination port, application ID, protocol, outgoing packet count, outgoing packet byte count) (where available).

[0129] In an exemplary embodiment, logistic regression is used (based on linear regression), where the result of the logistic regression is a probability that can be used as a confidence level for device identification. An exemplary formula for logistic regression is as follows:

[0130]

[0131] Here, b=e. Features are extracted from packet flows during sessions to train models, and the resulting trained models can then be used to identify devices. The resulting models generate coefficients for each feature. These sets of coefficients can be used as behavioral signatures for the devices (referred to as 'behavioral signatures' here).

[0132] Gaussian Naive Bayes Other types of classifiers, such as K nearest neighbors, decision trees, random forests, and / or vector machines, may also be used according to the techniques described herein (including using the features described herein).

[0133] 1. Packet Length Sequence (SPLN)

[0134] A packet length sequence (SPLN) can be obtained for a given flow by determining, for example, the lengths of the first 10 (or other appropriate number) non-zero packet length packets (payloads) of the flow. If a given packet in the sequence has a payload length of 0, that packet may be skipped and the next packet length may be examined (until the required 10 or other amount of non-zero packet lengths are considered). If the given flow has fewer than the total number of non-zero packet lengths (for example, if the entire flow consists of only 7 non-zero packets), the SPLN may be padded with zeros at the end to reach the configured number of packet lengths (e.g., 10).

[0135] 2. Sequence of arrival times between packets (SPIT)

[0136] FIG. 12 illustrates a sequence of arrival times between packets (SPITs). As illustrated, "Time1" represents the time between the reception of the first packet (Packet 0) and the second packet (Packet 1). "Time2" represents the time between the reception of the second packet and the third packet (Packet 2), and thereafter. As with the SPLN described above, in some embodiments, SPITs are determined only for non-zero length packets. For example, as illustrated in FIG. 12, if Packet 2 has a payload of zero length, the delta between the reception times of Packet 3 and Packet 1 is used (and a total of 10 or other appropriate number of arrival times between packets are determined between the first 11 or other appropriate number of non-zero length packets).

[0137] 3. Transport Layer Security (TLS)

[0138] When a device (e.g., an IoT device) participates in an encrypted traffic session, the first part of the session is a clear handshake. Information from this handshake can be captured, and information about the handshake is extracted. Examples of such information include: the TLS version, the order list of offered ciphersuits (e.g., in a client hello message), the list of supported TLS extensions (e.g., in a client hello message), the selected ciphersuit (e.g., in a server hello response message), the selected TLS extensions (e.g., in a server hello response message), and the public key length. Like the previously mentioned packet metadata, SPLN, and SPIT information, TLS information can also be used as a feature in determining packet behavior signatures.

[0139] C. Yes - SampleCo Smart Meter

[0140] The following is a simplified example of using the techniques described herein to train a model to recognize a SampleCo brand smart meter (e.g., a water meter that collects data on water usage and time and transmits the collected data to a network for billing purposes, such as with a water company). SampleCo smart meters exhibit various characteristics, such as communicating via NTP, TCP, and FTP both internally (via an intranet) and externally (e.g., to an external server).

[0141] Positive and negative training data (in relation to SampleCo smart meters) are collected and provided to the training module (241) (e.g., by an investigator). An example of this data is illustrated in FIG. 13a. In the illustrated example, a total of 10 training samples were provided (each numbered 0 through 9). Column 1302 indicates whether a given sample is a positive sample (indicated by "1") or a negative sample (indicated by "0"). Thus, the first 5 devices are SampleCo smart meters, and the last 5 devices are not. Each of the remaining 9 columns (1304) corresponds to a single feature. For example, they include OUIs (1306), protocol (1308), destination port (1310), packet length (1312), and packet timing information (1314). In various embodiments, this sample data may be obtained using one or more Python scripts configured to parse traffic flow logs. When examining the training data for Device 0 (a positive example of a SampleCo smart meter), it has an OUI of 6935 and communicates using Protocol 6 (e.g., FTP) over Port 21. It was observed that the first three non-zero packets of Device 0 are 21 bytes, 26 bytes, and 22 bytes, respectively. In this exemplary data set, the first packet time (t0) is always 0, and the delta between each time (e.g., t1-t0, etc.) is determined by the training module (241). Other forms of data may also be used (e.g., where the delta is determined by a Python script and displayed instead of each time listed in area 1314).

[0142] FIG. 13b illustrates the results of training a model using the dataset shown in FIG. 13a. In particular, the coefficients and intercepts of the model for determining whether traffic corresponds to a SampleCo smart meter are shown. The coefficients / intercepts shown in FIG. 13b represent examples of behavioral signatures of SampleCo smart meter devices in their entirety and may be stored (e.g., in a database (160) or other appropriate location) for use in the subsequent identification of other SampleCo smart meter devices (e.g., these may be added to a network (110) and the traffic received by a data appliance (102)).

[0143] Figure 14a illustrates two examples of devices matching the device behavior signature. The two rows indicated in area 1402 correspond to data collected from two devices, namely Device 0 and Device 1. Both of these devices are SampleCo smart meter devices. Area 1404 indicates the probability that each device is not a SampleCo smart meter (for Device 0 in the top row and Device 1 in the bottom row). Area 1406 indicates the probability that each device is a SampleCo smart meter (for Device 0 in the top row and Device 1 in the bottom row). Both devices match the SampleCo smart meter device behavior profile with a probability of 99% or higher.

[0144] Figure 14b illustrates two examples of devices that do not match the device behavior signature. The two rows indicated in area 1452 correspond to data collected from two devices, namely Device 0 and Device 1. Neither of these devices is a SampleCo smart meter device. Area 1454 indicates the probability that each device is not a SampleCo smart meter (for Device 0 in the top row and Device 1 in the bottom row). Area 1456 indicates the probability that each device is a SampleCo smart meter (for Device 0 in the top row and Device 1 in the bottom row). Based on the behavior profile, the probability that both devices are SampleCo smart meter devices is less than 1%.

[0145] D. Process for performing device identification

[0146] Models trained using the techniques described herein can be used for various purposes. As previously mentioned, one of these purposes is to efficiently perform inline device identification / classification (e.g., classification performed in real-time when traffic associated with a device is observed in a network). Another purpose is to perform offline analysis (e.g., PCAP or other previously captured network traffic files). In both inline and offline device classification, a model is trained using device datasets and other traffic (e.g., using logistic regression) to generate a set of coefficients for each device. The set of coefficients for each device can be used as device behavior signatures. The set of coefficients can then be fed to the model for use in device identification. Features extracted (from pcap files or from live traffic by a security appliance such as a firewall) are provided to a device identification engine (e.g., implemented by the analysis engine (242) and related elements shown in FIG. 2g). The device identification engine generates as output the probability that a given device matches the considered device behavior signature. Each possible device behavior signature can be repeated, and the one with the highest probability (e.g., based on a quality threshold) can be assigned as the device classification.

[0147] FIG. 15 illustrates an example of a process for classifying IoT devices. In various embodiments, the process (1500) is performed by a security platform (140). The process (1500) may also be performed by other applicable systems (e.g., systems deployed on-premises with IoT devices). The process (1500) begins at 1502 when information related to network communication of an IoT device is received. For example, this information is received by the security platform (140) when a data appliance (102) transmits a device discovery event for a given IoT device to the security platform (140). At 1504, a decision is made that the device is not classified (or, if applicable, that reclassification should be performed). For example, the platform (140) may query a database (286) to determine whether the device is classified. At 1506, a comparison of one or more behavior signatures is performed. For example, as previously mentioned, various different machine learning and rule / heuristic-based models may be used by the inline analysis engine (272). These models may be applied individually or (more generally) collectively, and different types of models may be well applied to detect specific types of devices. As previously mentioned, in some situations, machine learning models that use packet behavior information may be efficient for classifying devices. In various embodiments, in 1506, one or more such models are used to identify a given IoT device. In particular, in 1506, a probability match for such models is determined. And, if a given device has a probability match exceeding a threshold for a given packet behavior signature, the device may be classified as a specific type (e.g., a device type corresponding to the matched profile) (e.g., by the platform (140)).Finally, in 1508, the classification of IoT devices (e.g., as done in 1506) is provided to a security appliance configured to apply policies to IoT devices. As mentioned above, this enables highly granular security policies to be implemented in potentially mission-critical environments with minimal management effort.

[0148] Although the aforementioned embodiments have been described in some detail for clarity of understanding, the present invention is not limited to the details provided. There are many alternative methods for implementing the present invention. The disclosed embodiments are exemplary and not limiting.

Claims

Claim 1 A system comprising: a processor; receiving information associated with network communication of an Internet of Things (IoT) device; determining whether the IoT device has previously been classified as a specific type of IoT device; and in response to the determination that the IoT device has not previously been classified as said specific type of IoT device, determining that the probability match of the IoT device for a behavior signature exceeds a threshold—wherein the behavior signature is generated by using a machine learning model trained with features extracted from at least partially a typical IoT device of a specific type, determining the probability match includes using at least one machine learning model trained using packet behavior information, and determining that the probability match exceeds a threshold includes determining that multiple signatures match above the threshold and, as a result, selecting the highest-ranking match—; the processor configured to provide the classification of the IoT device to a security appliance configured to apply a policy to the IoT device based at least partially on the probability match; and a memory coupled to the processor and configured to provide instructions to the processor. Claim 2 A system according to claim 1, wherein the packet behavior information used to train at least one machine learning model includes a sequence of packet length information. Claim 3 A system according to claim 1, wherein the packet behavior information used to train at least one machine learning model includes a sequence of arrival time information between packets. Claim 4 A system according to claim 1, wherein the packet behavior information used to train at least one machine learning model includes transport layer security (TLS) information. Claim 5 In paragraph 1, a system in which an Organization Unique Identifier (OUI) for an IoT device is not available. Claim 6 In paragraph 1, the OUI for the IoT device corresponds to a network card, and the IoT device is a system that is not a network card. Claim 7 In paragraph 1, the OUI for the IoT device corresponds to a network appliance, and the IoT device is a system that is not a network appliance. Claim 8 A system in which at least a portion of the network communication is encrypted, as in paragraph 1. Claim 9 In paragraph 1, a system in which the host name for the IoT device is not available. Claim 10 In claim 1, the system, wherein the behavior signature comprises a set of coefficients. Claim 11 In claim 1, the probability match is associated with an IoT device manufactured by a specific vendor, in a system. Claim 12 In claim 1, the probability match is a system associated with an IoT device having a specific function. Claim 13 A method comprising: receiving information related to network communication of an Internet of Things (IoT) device; determining whether the IoT device has previously been classified as a specific type of IoT device; determining, in response to the determination that the IoT device has not previously been classified as a specific type of IoT device, that the probability match of the IoT device for a behavior signature exceeds a threshold value—wherein the behavior signature is generated by using a machine learning model trained with features extracted from a typical IoT device of a specific type at least partially, and determining the probability match includes using at least one machine learning model trained using packet behavior information, and the step of determining that the probability match exceeds a threshold value includes determining that a plurality of signatures match above the threshold value and selecting the highest-ranking match as a result—; and providing a classification of the IoT device to a security appliance configured to apply a policy to the IoT device at least partially based on the probability match. Claim 14 A computer program comprising computer instructions stored on a non-transient computer-readable medium, wherein the computer instructions: receive information associated with network communication of an Internet of Things (IoT) device; determine whether the IoT device has previously been classified as a specific type of IoT device; and in response to the determination that the IoT device has not previously been classified as a specific type of IoT device, determine that the probability match of the IoT device for a behavior signature exceeds a threshold—wherein the behavior signature is generated by using a machine learning model trained with features extracted from a typical IoT device of a specific type at least partially, and determining the probability match includes using at least one machine learning model trained using packet behavior information, and determining that the probability match exceeds a threshold includes determining that a plurality of signatures match above the threshold and, as a result, selecting the highest-ranking match—; and, at least partially based on the probability match, provide a classification of the IoT device to a security appliance configured to apply a policy to the IoT device.

Images