IT security policy in firewall

Abstract

Techniques for implementing policies over Internet of Things (IoT) device communications are disclosed. Information related to network communication of an IoT device is received. The received information, including the device type, is used to determine a device profile to be associated with the IoT device. A recommended security policy to be applied to the IoT device is generated by a security device.

Description

Technology Field

[0001] Cross-reference to other applications

[0002] This application is a partial continuation of U.S. Patent Application No. 17 / 381,103, filed July 20, 2021, titled IoT Device Discovery and Identification, which is the continuation applicant of U.S. Patent Application No. 17 / 133,189, titled IoT Device Discovery and Identification, filed December 23, 2020, which is currently U.S. Patent No. 11,115,799, claiming priority to U.S. Provisional Patent Application No. 63 / 033,004, titled IoT Device Discovery and Identification, filed June 1, 2020, each of which is incorporated herein by reference for all purposes. Background Technology

[0003] Unscrupulous individuals attempt to compromise computer systems in various ways. For example, these individuals may embed malicious software ("malware") in email attachments or otherwise transmit it, or have it sent to unsuspecting users. When executed, malware damages the victim's computer and can perform additional unscrupulous tasks (e.g., leaking sensitive data, spreading to other systems, etc.). Various approaches can be used to harden computers against these and other forms of damage. Unfortunately, existing approaches to protecting computers are not necessarily suitable for all computing environments. Furthermore, malware creators continue to adapt their techniques to evade detection, and there is an ongoing demand for improved methods to detect malware and prevent its harmful effects in various situations.

[0004] The present invention may be embodied in a number of ways, including a process; a device; a system; a composition of a material; a computer program product embodied on a computer-readable storage medium; and / or a processor such as a processor that is stored on memory coupled to the processor and / or configured to execute instructions provided by it. In this specification, these embodiments, or any 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 described, a component such as a processor or memory described as configured to perform a task may be embodied as a general component temporarily configured to perform a task at a set time or as a specific component manufactured to perform a task. As used herein, the term 'processor' refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0005] A detailed description of one or more embodiments of the present invention is provided below, together with the accompanying drawings illustrating the principles of the present invention. Although the present invention is described in relation to these embodiments, the present invention is not limited to any of the embodiments. The scope of the present invention is limited only by the claims and includes a number of alternatives, modifications, and equivalents. A number of specific details are provided in the following description to provide a thorough understanding of the present invention. These details are provided for illustrative purposes, and the present 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 present invention has not been described in detail so as not to unnecessarily obscure the present invention.

[0006] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. Brief explanation of the drawing

[0007] Figure 1 illustrates an example of an environment where malicious activity is detected and its harmfulness is reduced. FIG. 2a illustrates an embodiment of a data device. FIG. 2b is a functional diagram of the logical components of an embodiment of a data device. Figure 2c illustrates an exemplary event path between an IoT server and an IoT module. Figure 2d illustrates an example of a device discovery event. Figure 2e illustrates an example of a session event. FIG. 2f illustrates an embodiment of an IoT module. Figure 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 embodiment of an IoT module. Figure 6 illustrates an example of a process for classifying IoT devices. Figures 7a and 7b illustrate exemplary firewall rules. FIGS. 8 through 10 illustrate parts of exemplary interfaces. FIG. 11 illustrates an example of a process for creating a policy to be applied to communication involving IoT devices. Specific details for implementing the invention

[0008] I. Overview

[0009] Firewalls generally protect networks from unauthorized access while allowing authorized communications to pass through the firewall. 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 systems of devices (e.g., computers, smartphones, or other types of network-communicable devices). A firewall can also be integrated into 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 devices (e.g., security devices or other types of special-purpose devices), and in various embodiments, specific operations may be implemented in special-purpose hardware, such as an ASIC or FPGA.

[0010] Firewalls typically deny or allow network transmissions based on sets 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 using sets of rules or policies to prevent unwanted outside traffic from reaching protected devices. A firewall can also filter outbound traffic by using sets of rules or policies (e.g., allow, block, monitor, notify, or log, and / or other actions may be specified in firewall rules or firewall policies, which may be triggered based on various criteria as described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly using sets of rules or policies.

[0011] Security devices (e.g., security devices, security gateways, security services, and / or other security devices) may include various security functions (e.g., firewalls, malware prevention, 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.

[0012] Basic packet filtering firewalls filter network communication traffic by examining individual packets transmitted through the network (e.g., packet filtering firewalls or first-generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically examine the individual packets themselves and apply rules based on the examined packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port number).

[0013] Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second-generation firewalls, which 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 Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfer using File Transfer Protocol (FTP), 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 sneak through by using non-standard ports for the aforementioned protocols can generally be identified using application firewalls).

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

[0015] Advanced or next-generation firewalls can perform stateless and stateful packet filtering and application layer filtering, as discussed above. Next-generation firewalls can also perform additional firewall techniques. For example, certain newer 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 extend the list of applications that these firewalls can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' PA series firewalls). For example, Palo Alto Network's next-generation firewalls enable enterprises to identify and control applications, users, and content—rather than 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 a 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 enable application usage using business-related concepts, instead of following the conventional approach provided by traditional port-blocking firewalls.In addition, special-purpose hardware for next-generation firewalls (e.g., implemented as dedicated devices) generally provides higher performance levels for application inspection than software running on general-purpose hardware (e.g., security devices provided by Palo Alto Networks, Inc. that use dedicated, function-specific processing tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).

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

[0017] II. Exemplary Environment

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

[0019] Examples of these policies include controlling traffic shaping, 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 delivery. In some embodiments, the data device (102) is also configured to enforce policies on traffic remaining within the corporate network (110).

[0020] 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 the Lightweight Directory Access Protocol (LDAP) or other suitable protocols. The directory service (154) is configured to manage user identity and credential information. One example of the directory service (154) is the Microsoft Active Directory Server. Other types of systems, such as Kerberos-based systems and techniques adapted accordingly and described herein, may also be used in place of the Active Directory Server. 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 correct devices for policy compliance before granting access to the network, distinguish access based on rules, and then audit and report who is on the network. An example of an AAA server (156) is a Cisco Identity Services Engine (ISE) server that uses the Remote Authentication Dial-In User Service (RADIUS). Other types of AAA servers, including those using protocols other than RADIUS, may be used in conjunction with the techniques described herein.

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

[0022] Although depicted in FIG. 1 as having a single data device (102), a given network environment (e.g., network (110)) may include multiple embodiments of data devices, whether they operate individually or in cooperation. Similarly, the term “network” is generally referred to in the singular form (e.g., as “network (110)”) for simplicity in this document, but the techniques described herein may be deployed 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.

[0023] The data device (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-malicious files, domains, etc., to data devices such as the data device (102) as part of a subscription. As will be 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., related to samples, applications, domains, etc.) are stored in the database (160). In various embodiments, the security platform (140) comprises one or more dedicated commercially available hardware servers running conventional 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 including multiple such servers, solid-state drives or other storage devices (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, parts or all of the security platform (140) may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3).In addition, just as with the data device (102), whenever the security platform (140) is referred to as performing a task such as storing data or processing data, it will be understood that a sub-component or multiple sub-components of the security platform (140) (whether individually or in cooperation with third-party components) may cooperate to perform said task. 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 including 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, which is provided by dedicated hardware where the rest of the security platform (140) is owned by and under the control of the operator of the security platform (140).

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

[0025] The functions described herein as being performed by the data device (102) may be provided / implemented in various ways. For example, the data device (102) may be a dedicated device or a set of devices. A given network environment may include multiple data devices, each 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 device (102) may also be integrated into software on a general-purpose computer, a computer server, a gateway, and / or a network / routing device, or executed thereon. In some embodiments, at least some functions described as being provided by the data device (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. The functions described herein as being performed by the data device (102) may also be performed at least partially by the security platform (140) or in cooperation with it, and / or the functions described herein as being performed by the security platform (140) may also be performed at least partially by the data device (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).

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

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

[0028] As described, the data device (102) includes a firewall and includes a management plane (212) and a data plane (214). The management plane is responsible for managing user interactions, for example, by configuring policies and providing a user interface for viewing log data. The data plane is responsible for managing data, for example, by performing packet processing and session handling.

[0029] The network processor (216) is configured to receive packets from client devices, such as the client device (108), and to provide them to the data plane (214) for processing. Whenever the flow module (218) identifies a packet as part of a new session, it creates a new session flow. Subsequent packets will be identified as belonging to the session based on the flow index. Where applicable, SSL decryption is applied by the SSL decryption engine (220). Otherwise, processing by the SSL decryption engine (220) is omitted. The decryption engine (220) helps the data device (102) inspect and control SSL / TLS and SSH encrypted traffic, and thus helps stop threats that may be hidden in other 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 parameters such as URL category, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (which specify which 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.

[0030] The application identification (APP-ID) engine (222) is configured to determine what type of traffic a session involves. As an example, the application identification engine (222) may recognize a GET request in the received data and conclude that the session requires an HTTP decoder. In some cases, such as in a web browsing session, the identified application may change, and these changes will be noted by the data device (102). For example, the user may initially browse to a corporate Wiki (classified as "Web Browsing - Productivity" based on the visited URL) and then subsequently browse to a social networking site (classified as "Web Browsing - Social Networking" based on the visited URL). Different types of protocols have corresponding decoders.

[0031] Based on a decision made by the application identification engine (222), packets are sent by the threat engine (224) to an appropriate decoder configured to collect the packets (which may be received out of order), perform tokenization, and extract information. The threat engine (224) also performs signature matching to determine what should happen to the packets. As required, the SSL encryption engine (226) can re-encrypt the decrypted data. The packets are forwarded using a forward module (228) for transmission (e.g., to a destination).

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

[0033] III. IoT Device Discovery and Identification

[0034] Returning to FIG. 1, let us assume that a malicious individual (e.g., using the system (120)) has created malware (130). The malicious individual hopes that vulnerable client devices will execute a copy of the malware (130), thereby compromising the client devices and causing them to become bots in a botnet. The compromised client devices may then perform tasks (e.g., cryptocurrency mining, participating in fraudulent service attacks, and spreading to other vulnerable client devices), report information, or leak other data to an external entity (e.g., a command and control (C&C) server (150)), as well as receive instructions from the C&C server (150) where applicable.

[0035] Some of the client devices depicted in FIG. 1 are commercial computing devices commonly used within corporate organizations. For example, client devices (104, 106, and 108) each run common operating systems (e.g., macOS, Windows, Linux, Android, etc.). These commercial computing devices are often supplied and maintained by administrators (e.g., as company-issued laptops, desktops, and tablets, respectively) and often operate with user accounts (e.g., managed by a directory service provider configured with user identity and credential information (also referred to as a domain controller)). As an example, an employee named Alice may be issued a laptop (104) that she uses to access ACME-related emails and perform various ACME-related tasks. Other types of client devices (commonly referred to herein as Internet of Things or IoT devices) are also increasingly present in networks and are often "unmanaged" by IT departments. Some of these devices (e.g., teleconference devices) may be found across various different types of enterprises (e.g., as 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 may be found within a medical enterprise network (e.g., network (110)), and robotic arms are examples of devices that may be found in a manufacturing enterprise network. In addition, consumer-oriented IoT devices (e.g., cameras) may also exist in enterprise networks. Like commercial computing devices, IoT devices existing within a network may communicate with resources located either inside or outside of these networks (and both, where applicable).

[0036] Like commercial computing devices, IoT devices are targets for unscrupulous individuals. Unfortunately, the presence of IoT devices in a network poses several unique security and management challenges. IoT devices are often low-power or special-purpose devices and are frequently deployed without the knowledge of network administrators. Even when these administrators are aware of them, it may not be possible to install endpoint protection software or agents on the IoT devices. IoT devices are managed by third-party cloud infrastructure using proprietary (or other non-standard) protocols and may communicate directly with it (e.g., an industrial thermometer (152) communicating directly with the cloud infrastructure (126)). This can confuse attempts to monitor network traffic on these devices or elsewhere to make judgments about when a threat or attack is occurring against the device. Furthermore, some IoT devices (e.g., in medical settings) are mission-critical (e.g., network-connected surgical systems). Unfortunately, damage to an IoT device (e.g., by malware (130)) or misuse of security policies for traffic associated with an IoT device can have potentially fatal effects. By using the techniques described herein, the security of heterogeneous networks containing IoT devices can be improved and the harmfulness posed to such networks can be reduced.

[0037] In various embodiments, the data device (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). This identification may be used, for example, by the data device (102) to help create and enforce policies regarding traffic associated with IoT devices, and to enforce the functions of other elements of the network (110) (e.g., providing context information to AAA (156). In various embodiments, the IoT server (134) includes one or more network sensors configured to passively scan and monitor traffic. One exemplary method for providing such network sensor functions is as a tap interface or a switch mirror port. Other approaches for monitoring traffic may also be used if applicable (additionally or instead).

[0038] In various embodiments, the IoT server (134) is configured to provide logs or other data (e.g., collected from passively monitoring the network (110)) to the IoT module (138) (e.g., via the 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, discovery events are transmitted by the IoT server (134) whenever it observes a packet that can uniquely identify or verify the identity of the device (e.g., whenever a DHCP, UPNP, or SMB packet is observed). Each session held by the device (with other nodes, whether 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 arranged 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).

[0039] One exemplary way to implement the IoT module (138) is to use a microservices-based architecture. The IoT module (138) may also be implemented, where applicable, using different programming languages, databases, hardware, and software environments, and / or as services that are messaging-enabled, defined by contexts, self-deployable, independently deployable, decentralized, and built and released with automation 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 devices such as data devices (136 and 148)) and to provide additional context information about these devices (e.g., again to each data device).

[0040] FIG. 2f illustrates an embodiment of an IoT module. Area (285) depicts a set of Spark applications running at intervals (e.g., every 5 minutes, every hour, and every day) across the data of all tenants. Area (297) depicts a Kafka message bus. Session event messages received by the IoT module (138) (e.g., from the IoT server (134)) are grouped together as observed by 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 combined by the aggregation module (238) using various different aggregation rules. An exemplary rule is "collect all event data for a specific device and each (APP-ID) application used by it during a time interval (e.g., 5 minutes)." Another exemplary rule is to “collect all event data for a specific device that communicated 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 that need to be combined (e.g., a list of applications used by the device or a list of destination IP addresses). The feature extraction module (240) extracts features (252) from the attributes. The analysis module (242) uses the extracted features to perform device classification (e.g., using supervised and unsupervised learning), and the results of its (254) are used to operate other types of analysis (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 analysis related to the OT framework and operational or business intelligence (e.g., how the device is being used). Alerts (256) may be generated based on the results of the analysis.In various embodiments, MongoDB (258) is used to store aggregated data and feature values. Background services (262) receive aggregated data from Spark applications and write the data to MongoDB (258). An API server (260) pulls and merges data from MongoDB (258) to provide requests received from the front end (142).

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

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

[0043] 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 a session (such as file downloads, login / authentication processes, or disk backup activities) and attach any applicable tags based on the received feature values / session information. One way to implement activity classification (278) is through a neural network-based multi-layer perceptron combined with a convolutional neural network.

[0044] As a result of activity classification, it is assumed that a particular device is engaged in printing activities (i.e., using printing protocols) and also periodically contacts resources owned by HP (e.g., to check for updates by calling HP URLs and using them to report status information). In various embodiments, classification information is passed to both a clustering processor (unsupervised) and a prediction process (supervised). If either process causes a successful classification of the device, the classification is stored in the device database (286).

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

[0046] As illustrated in FIG. 2g, activity classification information is also provided as a set of classifiers (282), and predictions are made based on the provided features for the device. Two possibilities may occur. In the first scenario, it is determined that there is a high probability that the device matches a known device profile (i.e., a high confidence score). Then, information about the device is provided to a Stage 2 classifier (284) that makes a final determination on the identification of the device (e.g., using the provided information and any additional applicable contextual information) and updates the device database (286) accordingly. One way to implement the Stage 2 classifier is to use a gradient boosting framework. In the second scenario, let us assume that the confidence score is low (e.g., the device matches both an HP printer and an HP laptop with 50% confidence). In this scenario, the information determined by the classifiers (282) may be provided to the clustering engine (280) as additional information available for clustering.

[0047] Also, in Fig. 2G, an offline modeling module (299) is illustrated. The offline modeling module (299) is contrasted with the inline analysis engine (272) because it is not time-limited (whereas the inline analysis engine (272) attempts to provide device classification information in real time (e.g., as a message (234))). Periodically (e.g., once daily 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), which is also used for device type models (286) used by classifiers for device identification during inline analysis. The baseline modeling engine (290) constructs models of baseline behaviors of device models, which are also used to model specific types of device anomalies (292) and specific types of threats (294), such as a kill chain. In various embodiments, the generated models are stored in a model database (298).

[0048] IV. Network Entity ID AAA

[0049] As previously mentioned, let us assume that Alice is issued a laptop (104) by ACME. Various components of the network (110) will cooperate to authenticate Alice's laptop as she uses it to access various resources. As one example, when Alice connects the laptop (104) to a wireless access point (not described) located within the network (110), the wireless access point may communicate with the AAA server (156) while defining network access (either directly or indirectly). As another example, when Alice uses the laptop (104) to access her ACME email, the laptop (104) may communicate with the directory service (154) while retrieving her inbox, etc. (either directly or indirectly). As a commercial laptop running a commercial operating system, the laptop (104) may generate appropriate AAA messages (e.g., RADIUS client messages) to help the laptop (104) obtain access to the appropriate resources it requires.

[0050] As previously mentioned, one problem raised by IoT devices (e.g., device (146)) in a network such as 110 is that they are often "unmanaged" (e.g., not configured, defined, 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 may be adopted to provide network access to IoT devices within the network (110), each having its disadvantages. One option is to restrict IoT devices to the use of the guest network for 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) to which it is legally required to access. Another option is to allow IoT devices unrestricted access to the network (110), thereby mitigating the security benefits of a partitioned network. Another option is to manually specify rules for ACME that control how a given IoT device should be able to access resources in the network (110). This approach is generally unusable / unoperable for various reasons. For example, administrators may not often be involved in the deployment of IoT devices and therefore may not know whether policies for these devices should be included (e.g., in the data device (102)). Even if administrators manually configure policies for specific IoT devices (e.g., devices such as device (112)) in the device (102), keeping these policies up to date is prone to errors and is generally unusable considering the net number of IoT devices that may exist in the network (110).Furthermore, these policies are likely to be simple (e.g., assigning the CT scanner (112) to a specific network by an IP address and / or MAC address) and do not allow for more sophisticated control over connections / policies involving the CT scanner (112) (e.g., dynamically including policies applicable to surgical devices versus point-of-sale management terminals). Furthermore, even if the CT scanner (112) is passively included in the data device (102) as previously mentioned, IoT devices generally do not support technologies such as RADIUS, and the benefits of these AAA servers managing networking access to the CT scanner (112) will be limited compared to other types of devices (e.g., laptops (104)) that more fully support these technologies. As will be described in more detail below, in various embodiments, the data device (102) (e.g., via the IoT server (134)) is configured to provide support for AAA functions to IoT devices present in the network (110) in a passive manner.

[0051] In the following discussion, it is assumed that Alice’s department at ACME has recently purchased an interactive whiteboard (146) to enable Alice to collaborate with other ACME employees as well as individuals outside ACME (e.g., Bob, a researcher at Beta University with his own network (114), data device (136), and whiteboard (144). As part of the initial setup of the whiteboard (146), Alice connects it to a power source and provides it 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) establishes a network connection, the IoT server (134) (e.g., via a mechanism such as a network sensor as described above) will recognize the whiteboard (146) as a new device within the network (110). 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 any 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 (and stored in) a data device (102) which, if applicable, can consequently provide it to the directory service (154) and / or AAA server (156). If applicable, the IoT module (138) may provide updated context information for the whiteboard (146) to the data device (102) as it becomes available. The data device (102) (e.g., via the IoT server (134)) can similarly provide ongoing information about the whiteboard (146) to the security platform (140).Examples of such information include observations of the behavior of the whiteboard (146) on the network (110) (e.g., statistical information regarding one of its connections) that can be used by the security platform (140) to build behavior profiles for devices such as the whiteboard (146). Similar behavior 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 abnormal behaviors. As an example, a data device (148) may use information provided by the security platform (140) to detect whether the thermometer (152) is behaving unusually compared to historical observations of the thermometer (152) and / or compared to other thermometers (not described), including thermometers of similar models, manufacturers, or more generally, other networks. If abnormal behavior is detected (e.g., by the data device (148)), appropriate corrective measures can be automatically taken, such as restricting access of the thermometer (152) to other nodes on the network (116) or generating an alarm.

[0052] 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 when a set of packets transmitted by the IoT device is acquired in 302. As an example, when the whiteboard (146) is first established on the network (110), these packets may be passively received by the IoT server (134) in 302. The packets may also be received during subsequent use of the whiteboard (146) in 302 (e.g., as Alice has whiteboarding sessions with Bob through the whiteboard (144)). In 304, at least one packet included in the set of data packets is analyzed. As an example of the processing performed in 304, the IoT server (134) determines that the packets received in 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. 4. As previously mentioned, the whiteboard (146) does not support the RADIUS protocol. However, the IoT server (134) may generate a message on behalf of the whiteboard (146) as depicted in FIG. 4a (e.g., using information received in 302 and also from the security platform (140), where applicable).As previously mentioned, when the IoT server (134) provides information about the whiteboard (146) to the IoT module (138), the IoT module (138) may perform various actions, such as creating a record about the whiteboard (146) in the database (160) and appending said record containing context information about the whiteboard. As additional context information about the whiteboard (146) is collected by the security platform (140), its profile may be updated and propagated to the data device (102). When the whiteboard (146) is initially defined within the network (110), no additional context information may 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 depicted 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 rich in this additional information. Examples of such subsequent messages are illustrated in FIG. 4b and FIG. 4c. FIG. 4b illustrates an example of a RADIUS message that the IoT server (134) can transmit on behalf of the whiteboard (146) once context information for the whiteboard (146) has been provided by the IoT module (138) (e.g., including a database of context information for a wide variety of IoT devices). In the example illustrated in FIG. 4b, contextual information such as the manufacturer of the whiteboard (Panasonic) and the characteristics of the device (e.g., it is an interactive whiteboard) is included.This context information can be used by AAA servers, such as an AAA server (156), to provide AAA services to the whiteboard (146) (without modifying the whiteboard (146)) by automatically defining it, for example, on a subnet dedicated to a remote conferencing facility. Other types of IoT devices can also be automatically grouped based on attributes such as device type, purpose, etc. (e.g., critical surgical equipment is automatically defined on a subnet dedicated to such equipment and thus separated from other devices on the network). This context information can be used to enforce policies such as traffic shaping policies, such as policies that provide priority processing to whiteboard (146) packets via social networking packets (e.g., as determined using an APP-ID). Sophisticated policies can be similarly applied to communications with critical surgical equipment (e.g., preventing any device from having an outdated operating system in communication with such equipment). In the example illustrated in FIG. 4c, additional contextual information is included in RADIUS messages by the IoT server (134) on behalf of the whiteboard (146). This additional contextual information includes additional attribute information such as device model, operating system, and operating version. When the whiteboard (146) is initially defined in the network (110), it is possible that not all of the contextual information depicted in FIG. 4c is available. As the whiteboard (146) is used within the network (110) over time, additional contextual information may be collected (e.g., as the IoT server (134) continues to passively observe packets from the whiteboard (146) and provide information to the security platform (140). This additional information may be leveraged to enforce sophisticated policies (e.g., by the data device (102)).As an example, as illustrated in FIG. 4c, the whiteboard (146) runs a specific operating system that is Linux-based and has version 3.16. Frequently, IoT devices will run versions of operating systems that are not upgradeable / unpatchable. These devices may pose security risks when exploits are developed for these operating systems. The data device (102) can implement security policies based on context information by isolating IoT devices with older operating systems from other nodes in the network (110) (or otherwise restricting their access), for example, while allowing less restrictive network access to those with current operating systems.

[0053] FIGS. 4a through 4c depict examples of RADIUS access request messages. Where applicable, the IoT server (134) may generate various types of RADIUS messages on behalf of the whiteboard (146). As an example, RADIUS billing start messages may be triggered when traffic from the whiteboard (146) is first observed. Periodic RADIUS billing intermediate update messages may be sent while the whiteboard is in use, and RADIUS billing stop messages may be sent when the whiteboard (146) goes offline.

[0054] V. IoT Device Discovery and Identification

[0055] 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) attempts to determine and respond to the classification of the device (e.g., with the determination (234) illustrated in FIG. 2c). The device is associated with a unique identifier by the IoT module (138) so that, where appropriate, subsequent classification of the device does not need to be performed (or, where applicable, less frequently than would otherwise be performed). Also, as discussed above, the determined classification can be used to enforce policies on traffic to / from the device (e.g., by the data device (102)).

[0056] Various approaches can be used to classify devices. The first approach performs classification based on a set of rules / heuristics that leverage the static attributes of the device, such as Organizational Unique Identifiers (OUIs) and the types of applications running on it. The second approach performs classification using machine learning techniques that leverage the dynamic, yet predefined, attributes of the device extracted from network traffic (e.g., the number of packets transmitted daily). Unfortunately, both of these approaches have weaknesses.

[0057] Rule-based approaches generally require that separate rules be manually generated for each type of IoT device (described which attributes / values ​​should be used as signatures for the type of device signature). One challenge posed by this approach is determining which signatures are relevant for identifying a device and are unique among other device signatures. Furthermore, with rule-based approaches, a limited number of static attributes are available that can be easily obtained from traffic (e.g., user agent, OUI, URL destination, etc.). Attributes generally need to be simple enough to be represented in patterns that regular expressions can match. Another challenge lies in identifying new static attributes that may exist and become identifiable as new devices enter the market (e.g., a new brand or model of a CT scanner is introduced). Another challenge is that all matching attributes must be collected from network traffic for a rule to be triggered. Decisions cannot be reached with fewer attributes. For example, a signature might require a specific device with a specific OUI to connect to a specific URL. While possessing the OUI itself may already be a sufficient indicator of the device's identity, the signature will not be triggered until the URL is also observed. This will cause an additional delay in determining the device's identity. Another challenge is maintaining and updating signatures as static attributes for device changes over time (e.g., due to updates made to the device or the services used by the device). For example, a particular device may have been manufactured using a Type 1 network card initially, but over time, the manufacturer may switch to a different network card (exhibiting a different OUI). If a rule-based system is unaware of these changes, false positives may occur.Another challenge lies in scaling signature generation and verification as the number of new IoT devices brought online daily reaches millions of new device instances. As a result, newly generated rules can conflict with existing rules, leading to false positives in classification.

[0058] Machine learning-based approaches generally involve generating training models based on static and / or dynamic features derived from network traffic. Predictions for network data from new IoT devices are based on pre-trained models that provide device identities with associated accuracy. Examples of problems associated with machine learning approaches include: The computational time required to achieve desired accuracy may be unacceptable, as predictions are performed on every new device or on devices lacking a fixed or unique ID (e.g., MAC address). There may be thousands or tens of thousands of features that need to be generated; transforming these features over a predefined time window can take a significant amount of time before a sufficient number of features are available for valid predictions (which can frustrate policy enforcement objectives). Furthermore, if the goal is to minimize prediction latency, the cost of building and maintaining large data pipelines for streaming network data can be high. Another issue is that noise caused by irrelevant features specific to a given deployment environment reduces prediction accuracy. There is a challenge in maintaining and updating models when the number of device types exceeds tens of thousands.

[0059] In various embodiments, the security platform (140) addresses the respective problems of the two aforementioned approaches by using a hybrid approach for 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 feature or behavior category) that form distinct network behavior descriptions and can be used to identify the type of IoT device. The pattern IDs are stored (e.g., in a database) and can be used to identify / verify the identity of the devices.

[0060] 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 (regardless of whether they are static or dynamic attributes, and / or aggregated / transformed values). Once established, a pattern ID can be used to uniquely identify a device type. If specific features are dominant for a device (e.g., a specific static feature (such as encountering a very specific URL at boot time) identifies the device with 98% confidence), they can be used to automatically generate rules. Even if dominant features do not exist, a representation of the top features can nevertheless be used as a pattern ID (e.g., when a set of multiple features is chained into a pattern). By training on a dataset containing all known models (and all known IoT devices), potential conflicts between models and uniquely identified features can be avoided. Furthermore, pattern IDs do not need to be human-readable (but can be stored, shared, and / or reused for identification purposes). Significant time savings can also be realized by this approach, and thus it can be used in near-real-time classification. As soon as a dominant feature is observed, classification of a specific device can occur (instead of having to wait until multiple features occur).

[0061] Examples of data that can be used to generate a pattern ID for the "Teem Room Display iPad" device may include the following (the full list is automatically generated by training a binary model or training multiple binary models):

[0062] * Apple devices (100%)

[0063] Special iPad (>98.5%)

[0064] * Teem Room app (>95%)

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

[0066] * Server-in-the-Cloud (>80%)

[0067] An exemplary method for implementing a hybrid approach is as follows. A neural network-based machine learning system can be used for automatic 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, matched L7 payload signatures, etc.) and sequential features extracted from network traffic but not specific to the environment (e.g., applications, L7 attributes of applications, volume ranges transformed into categorical features, etc.). A lightweight data pipeline can be used to stream selected network data in real time for feature generation. A prediction engine can be used to load models and provide caching to minimize latency during prediction. During prediction, short (e.g., minute-based) aggregation can be used to stabilize selected sequential features. Custom data normalization, reinforcement, aggregation, and transformation techniques can be used to engineer the sequential features. A longer aggregation window can be used during training for better accuracy. Accuracy can be improved for predictions where features are merged and aggregated over time. 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 expand the attributes used for pattern ID prediction. The device group model can be trained to compensate for issues with the device type model when sufficient samples or features are not available, in order to improve accuracy against an acceptable threshold (e.g., assigning prediction results based on a predefined set of types accompanied by another subsystem to cluster similar types of devices, some of which are unlabeled).Finally, the judgment module can be used to disclose results from the real-time prediction engine.

[0068] As described herein, exemplary benefits of a hybrid approach to classification 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 to prediction results. Fourth, it has scalability to support tens of thousands (or more) of different types of IoT devices. Predictions are generally required only for new devices (even if a given device lacks a unique ID assignment, such as L3 network traffic-based identification).

[0069] 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 in which the services are sophisticated and the protocols are lightweight. The services may also be implemented, where applicable, using different programming languages, databases, hardware, and software environments, and / or relatively small services that are messaging-enabled, limited by contexts, self-developed, independently deployable, decentralized, and built and released as automated processes.

[0070] As previously mentioned, in various embodiments, the security platform (140) periodically receives information about IoT devices on a network (e.g., network (110)) (e.g., from a data device (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., a whiteboard (146) is installed for the first time). Let us assume that a given device has not been previously classified by the security platform (140) (e.g., no entry for the device exists in the database (286) that stores a set of unique device identifiers and associated device information). As illustrated in FIG. 5, information about the 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 scheme) and pipeline (502) represents a “slow path” classification pipeline (corresponding to a machine learning-based scheme).

[0071] 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 built using the offline processing pipeline (506) based on top important features) (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., 0.9, based on the overall prediction accuracy of the module (138) or its components), a classification can be assigned to the device (in the device database (516)) or updated if applicable. Initially, the confidence score will be based on near-real-time fast path processing. The advantage of this approach is that the data device (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 device (102) may be configured to be fail-safe (e.g., reducing / limiting the device's ability to access various network resources) or fail-danger (allowing the device extensive access) by withholding classification judgment from the system (140). As additional information becomes available (e.g., through slow path processing), the confidence score may be based on said additional information where applicable (e.g., increasing the confidence score or revising / correcting errors made during fast path classification).

[0072] Examples of features that can be used (e.g., static attributes and sequence features) include the following. Pattern IDs may be any combination of the included logical conditions and these attributes:

[0073] OUI at MAC Address

[0074] Ilostname string from decoded protocols

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

[0076] System name string from decoded SNMP responses

[0077] OS, hostname, domain, and username from the decoded LDAP protocol

[0078] URLs from decoded DNS protocols

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

[0080] TCP flags

[0081] Option strings from decoded DHCP protocols

[0082] Strings from decoded IoT protocols such as Digital Imaging and Communications for Medical Use (DICOM)

[0083] List of inbound applications from the local network

[0084] List of inbound applications from the Internet

[0085] List of outbound applications to the local network

[0086] List of outbound applications to the Internet

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

[0088] List of inbound server ports from the Internet

[0089] List of outbound server ports to the local network

[0090] List of outbound server ports to the Internet

[0091] List of inbound IPs from the local network

[0092] List of inbound URLs from the Internet

[0093] List of outbound IPs to the local network

[0094] List of outbound URLs to the Internet

[0095] 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 (a new type of IoT toy or other type of product that has not been previously analyzed by the security platform (140)) and there is no corresponding pattern ID available for the device on the security platform (140). In such scenarios, information and classification results regarding the device may be provided to an offline processing pipeline (506) capable of performing clustering (514) on behaviors shown by the device and other application information (e.g., to determine that the device is a wireless device, acts like a printer, and uses the DICOM protocol). The clustering information may be used as labels and, if applicable, may have any subsequent similar devices that are automatically grouped together and flagged for further study (518). As a result of the study, when additional information about a given device is determined (e.g., identified as corresponding to a new type of consumer-oriented IoT meat thermometer), the device (and all other devices with similar properties) is relabeled accordingly (e.g., brand XYZ meat thermometer), and an associated pattern ID is generated and, if applicable (e.g., after the models have been rebuilt), can be made available by the pipelines (502.504). In various embodiments, offline modeling (520) is a process that runs daily to train and update the various models (522) used for IoT device identification. In various embodiments, the models are refreshed daily to cover new labeled devices and are rebuilt weekly to reflect behavioral changes (for the slow path pipeline (502)) and to accommodate new features and data insights added during the week.Note that when new types of devices are added to the security platform (140) (i.e., when new device patterns are created), it is possible to require that a number of existing device patterns be affected and that the list of features or their important scores be updated. The process can be performed automatically (and this is a significant advantage compared to rule-based solutions).

[0096] For rapid path modeling, neural network-based models (e.g., FNN) and general machine learning models (e.g., XGB) are widely used for multivariate classification models. Binary models are also built on selected profiles to help improve results and provide input for clustering. Binary models provide yes / no answers regarding the device's identity or specific behaviors. For example, a binary model can be used to determine whether a device is a type of IP phone or if it is unlikely to be an IP phone. A multivariate model will have many outputs normalized to a probability of 1. Each output corresponds to the type of device. Although binary models are generally faster, they would require processing many of them during prediction to find the correct "yes" answer for the device. A multivariate model can achieve this in a single step.

[0097] 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) will typically take some time to build. As an example, the feature "number of bytes sent per day" will require one day to collect. As another example, specific usage patterns may take some time to occur and be measured (e.g., a CT scanner is used to perform scans every hour (first behavior), backs up data daily (second behavior), and checks the manufacturer's website for weekly updates (third behavior)). The slow path pipeline (502) calls a multivariate classifier (526) in an attempt to classify new device instances on 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 Stage 1 prediction. When the Stage 1 prediction result is not optimal (having lower confidence) for specific profiles, Stage 2 prediction is used in an attempt to improve the result. The slow path pipeline (502) calls decision tree classifiers (528) supported by additional incoming device contexts to separate new device instances. The additional device contexts are provided from an external source. For example, a URL connected by the device may be provided with a risk-based reputation and category that may be included as features. As another example, an application used by the device may be provided with a risk-based score and category that may be included as features. By combining the results from the stage 1 prediction (526) and the stage 2 prediction (528), the final determination of the slow path classification can be reached as a derived confidence score.

[0098] Generally, there are two stages included in the slow path pipeline (502). In the slow path pipeline, in some embodiments, the stage 1 models are constructed with multivariate classifiers based on neural network techniques. Stage 2 of the slow path pipeline is generally a set of decision-based models with additional logic to handle probability-related exceptions of stage 1. When making a prediction, stage 2 will integrate the input from stage 1, apply rules and context to validate the stage 1 output, and generate the final output of the slow path. The final output will include the device identity, an overall confidence score, a pattern ID that can be used for 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 probability as part of the classification. The description list will include a list of features that contribute to the result. As mentioned above, if the result deviates from known pattern IDs, an investigation may be triggered.

[0099] In some embodiments, for slow path modeling, two types of models are constructed: one for individual identity and one for group identity. Often, it is more difficult to distinguish between two printers from different vendors or with different models, for example, to distinguish a printer from a thermometer (e.g., because printers exhibit network behavior and tend to speak similar protocols). In various embodiments, various printers from different vendors are grouped together, and a "printer" model is trained for group classification. The results of this group classification can provide better accuracy than a specific model for a specific printer and can be used to update the device's trust score or, where applicable, to provide criteria and validation for individual profile identity-based classification.

[0100] 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 systems where applicable (e.g., systems located in the same place as the IoT devices). The process (600) begins when information related to network communication of an IoT device is received in 602. As an example, this information is received by the security platform (140) when a data device (102) transmits a device discovery event for a given IoT device to it. In 604, a decision is made that the device is not classified (or, where applicable, re-classification should be performed). As an example, the platform (140) may query the database (286) to determine whether the device has been classified. In 606, a two-part classification is performed. For example, 2-part classification 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 summarized network behavior from baseline modeling (290), is provided to a security device configured to apply policies to the IoT device. Examples of these summarized network behaviors include the most used applications, URLs, and other attributes that can help form security device policies that can be "extracted" from machine-learning trained baseline models for IoT device profiles. As mentioned above, this allows highly sophisticated security policies to be implemented in potentially mission-critical environments with minimal management effort.

[0101] In the first example of performing the process (600), let us assume that an Xbox One game console is connected to the network (110). During classification, it may be determined that the device has the following dominant features: a "Vendor = Microsoft" feature with 100% confidence, a "communication with Microsoft cloud servers" feature with 89.7% confidence, and a "game console" feature with 78.5% confidence. These three features / confidence scores can be matched against a set of profile IDs to identify the device as an Xbox One game console as a whole (i.e., a profile ID match satisfying the threshold is found at 512) (a process performed by neural network-based prediction). In the second example, let us assume that an AudioCodes IP phone is connected to the network (110). During classification, a determination may be made that the device matches the "Vendor = AudioCodes" feature with 100% confidence, the "IP audio device" feature with 98.5% confidence, and the "act 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 no existing profile ID is matched with sufficient confidence. Information about the device can then be provided to a clustering process (514), and, where applicable, a new profile ID can ultimately be generated and associated with the device (and used to classify future devices).

[0102] Where applicable, the security platform (140) may recommend specific policies based on determined classification information, which is described in more detail below. The following are examples of policies that may be implemented:

[0103] Deny internet traffic for all infusion pumps (regardless of vendor)

[0104] Deny internet traffic to all GE ECC machines except from / to GE hosts.

[0105] For all CT scanners, only internal traffic to Picture Archiving and Communication System (PACS) servers is allowed (regardless of vendor).

[0106] VI. IoT Security Policies in Firewall

[0107] 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 laptops). As an example, regardless of the manufacturer (e.g., GE or Fujitsu), CT scanners will have similar functions and exhibit similar behaviors on a network, just like other CT scanners, such as transmitting captured patient images to a networked image server for medical staff to examine using one or more specific protocols (e.g., via an interface to the server). Other types of systems (e.g., heating, ventilation, and cooling (HVAC) systems) will exhibit their own set of similar, typically predefined behaviors (i.e., reporting temperature values ​​to a server once every minute via a specific protocol).

[0108] As mentioned above, the analysis of these behaviors from the observed traffic (e.g., by the data device (102)) (e.g., by the security platform (140)) allows specific IoT devices to be identified (including by identifying specific instances of the device, the model of the device, the manufacturer of the device, the type of the device, etc.). In addition, the byproduct of device identification will have a device baseline model trained for classification purposes (e.g., by the baseline modeling engine (290)). Where applicable, an anomaly detection module (248) may be used to filter out 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 may be used not only for device identity prediction but also to generate a common list of behavior summaries ranked by how popular the network behaviors appear in the device profile. One approach to behavior summarization is to use ML algorithms such as XGB to extract and rank top contributing features (used in device identification) from the baseline model during the training process. Other approaches may also be used or combined (e.g., heuristic approaches). Top contributing features (conditional on reliability / reliability thresholds) can be used in recommendations by highlighting the most common network behaviors exhibited by device types from the thousands of attributes or features used in training (e.g., whitelisting / blacklisting specific URLs, protocols, etc.). Behavior summarizations may include which applications are used, which connections are made to specific network domains, which payloads are carried by applications, volume, communication time, and frequency. 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., compromised or malfunctioning / misconfigured IoT devices) may be detected as deviations from baselines (e.g., by a data device (102) operating in conjunction 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 activities associated with specific IoT devices, device types, etc. For example, regularly used applications and URLs may be used to establish an "allow" firewall policy. In another example, applications that are not part of baseline behavior may be used to establish a "deny" firewall policy. Users may be able to adjust policies based on the frequency of network behavior summarized from hundreds of thousands of similar devices. Any known vulnerabilities (e.g., the sensitivity of a specific device to a specific attack) may be modeled separately where applicable and incorporated into the recommended policies. An example of a top-level feature for a given device type is that the device checks for updates almost daily at a specific URL (e.g., www.siemens.com / updates). If a threshold number of devices sharing the device type exhibit similar baseline behavior, the feature can be selected as a recommended whitelist item for device profiles associated with the said device type.

[0109] FIG. 7a illustrates a first approach to implementing a set of policies related to CT scanners / image servers that Acme can deploy within a network (110). Specifically, let us assume that Acme has deployed two types of CT scanners (manufactured by GE and Fujitsu). An administrator of the network (110) (hereinafter referred to as Charlie) interacts with an interface (e.g., provided by a data device (120) and / or a security platform (140), where applicable) and can manually specify, for each CT scanner and image server within the network (110), the protocols, ports, and IP addresses to which they are allowed to communicate. Unfortunately, this approach is time-consuming and prone to errors. For example, when a new CT scanner is added to the environment, Charlie manually adds the rules illustrated in FIG. 7a and may also potentially need to change or remove some of the rules (e.g., if the new CT scanner replaces an existing one and / or if network information changes). If the total number of IoT devices in the environment is low and the IoT devices are assigned static IP addresses, manual maintenance of rules as illustrated in Fig. 7a may be feasible. However, in reality, a given environment may have hundreds or thousands of IoT devices (or more) and / or use DHCP, and manual maintenance of rules is not feasible.

[0110] An alternative approach is to abstract applications (e.g., "DICOM-App," representing specific protocols / ports, etc., corresponding to network traffic used to transmit medical imaging information) and device types (e.g., GE-Xray-Device) according to the techniques described herein. The abstraction of rules illustrated in FIG. 7a is depicted in FIG. 7b. Of course, Charlie does not need to provide relevant IP addresses, ports, or protocols to the IoT policies; rather, abstract application types and device types may be used. Policies such as those illustrated in FIG. 7b can be compiled and used by the data device (102) at runtime. During compilation, the abstract elements (e.g., GE-Xray-Device) will be replaced (e.g., to the IP address of each IoT device that matches the device identification) based on information stored in the data device (such as APP-ID information, IP information, and / or a dictionary of device types).

[0111] Charlie may choose to manually record IoT device rules (e.g., using the aforementioned abstractions 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) and the baseline / typical behavior of a set of devices sharing various characteristics (across many different customer environments / deployments). If Charlie accepts the recommended policies, appropriate rules (e.g., rules as illustrated in FIG. 7b) are automatically generated (e.g., by the security platform (140)) and can be fed into the security device (102) for enforcement. The security device (102) will learn the device profiles of IoT devices on its network and match applicable policies to the devices as sources or destinations. Where applicable, policies can be converted into formats available to other types of infrastructure besides the security device (102), such as network access controllers (e.g., by the security platform (140)).

[0112] In the following discussion, let us assume that Acme has recently purchased a set of building automation devices (e.g., a set of badge readers), installed them in various Acme facilities, and brought the devices online as part of the network (110). Using the device identification / classification techniques described above, the security platform (140) (operating with the data device (102)) identifies that Acme has added 28 new badge reader devices to the network and will learn the various behaviors taken by these specific badge reader devices within Acme's network environment as they operate (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 currently has a total of 65 types of IoT devices (having corresponding profiles) operating in the environment. The newly added badge readers are depicted in row (802).

[0113] When Charlie clicks the link (804), he will go to the interface illustrated in FIG. 9. Area (902) indicates that the security platform (140) has identified 28 new devices as having high reliability and matching the Siemens Building Technology Device profile. Behavioral information collected for the 28 devices while operating within the Acme environment is also shown and summarized in area (904). In total, the 28 devices run 8 applications in the Acme environment, communicate with 23 destinations (22 within Acme and one outside), and currently have a risk score of 56. A count of how many of the 28 devices are using each application within the Acme environment is shown in area (906), and whether the destinations are internal or external is shown in area (908). Area (910) includes 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) behave across the environments of other customers of the security platform (140). As indicated in area (910), a typical customer deployment of Siemens Building Technology Devices uses three to five applications (912), causing the Acme deployment to be outside the typical range (914). If Charlie hovers his cursor over area (912), he will be provided with a box providing additional information about the comparison, such as:

[0114] "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 your Siemens Building Technology Devices was higher than usual. Review the application list."

[0115] Charlie can review the application list by scrolling further down the interface (900). As illustrated in FIG. 10, Charlie reviews the use of "dhep" and "bacnet" applications by badge reader devices after this scrolling. The "use" destination (1002) indicates the frequency of network usage patterns (device profile + application + URL (e.g., "www.siemens.com / update")) and / or destination profiles for IoT devices that share the profile (e.g., "PACS server"). In various embodiments, the use for each application is generated based on the traffic collected for the first time in a month. Charlie can use the usage information to determine whether he wants to allow or block specific behaviors. For example, considering that bacnet is not used frequently, he may learn that only internal domains should be allowed, or only predetermined external domains should be allowed (e.g., based on his knowledge of Acme's environment).

[0116] When Charlie clicks area (916) of the interface (900), he will be provided with two options 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). Once he clicks area (916) and chooses to use a recommended set of policies (if available), the security platform (140) will list any available recommended sets of policies, and Charlie can download / apply them to the Acme environment, having the ability to improve / adjust the policies if applicable (e.g., by interacting with various functions provided by the interface (800).

[0117] 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 systems where applicable (e.g., systems located in a corporate location with IoT devices). The process (1100) begins when information related to network communication of an IoT device is received in 1102. As an example, this information is received by the security platform (140) when a data device (102) transmits a device discovery event for a given IoT device (e.g., a badge reader device) to it. In 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 Device". Device types (e.g., badge reader devices) and device profiles (e.g., Siemens Building Technology Device) are generally referred to interchangeably in this section. However, multiple profiles may be created for a given device type (e.g., Siemens Building Technology Device devices located in Acme’s laboratory area versus Acme’s retail area), and a given profile may include multiple device types where applicable (e.g., a Siemens Building Technology Device profile may include badge reader devices and motion trigger sensors). Finally, in 1106, a recommendation policy to be applied to the IoT device by the security device is created.As an example, instead of allowing access to all eight applications shown in FIG. 9, the security device (140) may recommend a policy set that allows only three of the most commonly used badge reader applications (or five of the most commonly used badge reader applications) corresponding to the information shown in area (910). Once the recommended policy is downloaded and applied, if Charlie needs to make adjustments to the recommendation set (e.g., whitelisting bacnet), he can do so (e.g., by interacting with the “edit” option provided by the interface (800).

[0118] Although the foregoing 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 ways to implement the present invention. The disclosed embodiments are exemplary and not limiting.

Claims

Claim 1 A system comprising: a processor that receives information associated with network communication of an Internet of Things (IoT) device; uses said received information to determine a device profile including a device type to be associated with said IoT device; and is configured to generate a recommended security policy to be applied to said IoT device by a security device based at least partially on said device profile; and a memory coupled to said processor and configured to provide instructions to said processor, wherein said processor is configured to generate the recommended security policy based at least partially on said device profile by comparing said device profile with a plurality of other device profiles, said plurality of other device profiles correspond to a plurality of other devices sharing a device type. Claim 2 In claim 1, the system is configured such that the processor also determines whether the IoT device has been previously classified. Claim 3 In paragraph 2, the system is configured such that the processor also performs a classification process in response to determining that the IoT device has not previously been classified. Claim 4 A system according to paragraph 3, wherein performing the classification process includes performing inline classification and subsequent verification of the inline classification. Claim 5 A system according to claim 1, wherein the processor is also configured to generate instructions available to the security device for applying the recommended security policy. Claim 6 In paragraph 5, a system that generates the above instructions, including converting the above recommended security policy into vendor-specific instructions. Claim 7 In paragraph 1, the above information is received from the security device, in a system. Claim 8 In paragraph 1, the system, wherein the received information includes network traffic metadata. Claim 9 A system according to claim 1, wherein the IoT device is located in a first network environment and at least one other device sharing a device type with the IoT device is located in a second network environment different from the first network environment. Claim 10 A system according to claim 1, wherein comparing the device profile with the plurality of other device profiles includes determining the behavioral deviation of the IoT device from at least some of the plurality of other devices sharing the device type. Claim 11 In paragraph 1, the device type is a system that specifies a specific model of the IoT device. Claim 12 In paragraph 1, the device type is a system that specifies a specific vendor of the IoT device. Claim 13 In claim 1, the device type is a system that specifies the function provided by the device. Claim 14 A method comprising: receiving information associated with network communication of an Internet of Things (IoT) device; using said received information to determine a device profile including a device type to be associated with said IoT device; generating a recommended security policy to be applied to said IoT device by a security device at least partially based on said device profile; and generating said recommended security policy at least partially based by comparing said device profile with a plurality of other device profiles, wherein said plurality of other device profiles correspond to a plurality of other devices sharing a device type. Claim 15 A computer-readable storage medium storing a computer program, wherein the computer program includes computer instructions, and the computer instructions, when executed by a processor, cause the computer to: receive information associated with network communication of an Internet of Things (IoT) device; use said received information to determine a device profile including a device type to be associated with said IoT device; generate a recommended security policy to be applied to said IoT device by a security device at least partially based on said device profile; and generate said recommended security policy at least partially based by comparing said device profile with a plurality of other device profiles, said plurality of other device profiles corresponding to a plurality of other devices sharing a device type. Claim 16 delete Claim 17 delete

Images