Nefarious individuals attempt to compromise computer systems in a variety of ways. As one example, such individuals may embed or otherwise include malicious software (“malware”) in email attachments and transmit or cause the malware to be transmitted to unsuspecting users. When executed, the malware compromises the victim's computer and can perform additional nefarious tasks (e.g., exfiltrating sensitive data, propagating to other systems, etc.). A variety of approaches can be used to harden computers against such and other compromises. Unfortunately, existing approaches to protecting computers are not necessarily suitable in all computing environments. Further, malware authors continually adapt their techniques to evade detection, and an ongoing need exists for improved techniques to detect malware and prevent its harm in a variety of situations.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
A firewall generally protects networks from unauthorized access while permitting authorized communications to pass through the firewall. A firewall is typically a device, a set of devices, or software executed on a device that provides a firewall function for network access. For example, a firewall can be integrated into operating systems of devices (e.g., computers, smart phones, or other types of network communication capable devices). A firewall can also be integrated into or executed as one or more software applications on various types of devices, such as computer servers, gateways, network/routing devices (e.g., network routers), and data appliances (e.g., security appliances or other types of special purpose devices), and in various implementations, certain operations can be implemented in special purpose hardware, such as an ASIC or FPGA.
Firewalls typically deny or permit network transmission based on a set of rules. These sets of rules are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted outside traffic from reaching protected devices. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify or log, and/or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, such as are described herein). A firewall can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.
Security devices (e.g., security appliances, security gateways, security services, and/or other security devices) can include various security functions (e.g., firewall, anti-malware, intrusion prevention/detection, Data Loss Prevention (DLP), and/or other security functions), networking functions (e.g., routing, Quality of Service (QoS), workload balancing of network related resources, and/or other networking functions), and/or other functions. For example, routing functions can be based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.
A basic packet filtering firewall filters network communication traffic by inspecting individual packets transmitted over a network (e.g., packet filtering firewalls or first generation firewalls, which are stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect the individual packets themselves and apply rules based on the inspected packets (e.g., using a combination of a packet's source and destination address information, protocol information, and a port number).
Application firewalls can also perform application layer filtering (e.g., application layer filtering firewalls or second generation firewalls, which work on the application level of the TCP/IP stack). Application layer filtering firewalls or application firewalls can generally identify certain applications and protocols (e.g., web browsing using HyperText Transfer Protocol (HTTP), a Domain Name System (DNS) request, a file transfer using File Transfer Protocol (FTP), and various other types of applications and other protocols, such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, application firewalls can block unauthorized protocols that attempt to communicate over a standard port (e.g., an unauthorized/out of policy protocol attempting to sneak through by using a non-standard port for that protocol can generally be identified using application firewalls).
Stateful firewalls can also perform state-based packet inspection in which each packet is examined within the context of a series of packets associated with that network transmission's flow of packets. This firewall technique is generally referred to as a stateful packet inspection as it maintains records of all connections passing through the firewall and is able to determine whether a packet is the start of a new connection, a part of an existing connection, or is an invalid packet. For example, the state of a connection can itself be one of the criteria that triggers a rule within a policy.
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 are expanding 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 Networks' next generation firewalls enable enterprises to identify and control applications, users, and content—not just ports, IP addresses, and packets—using various identification technologies, such as the following: APP-ID for accurate application identification, User-ID for user identification (e.g., by user or user group), and Content-ID for real-time content scanning (e.g., controlling web surfing and limiting data and file transfers). These identification technologies allow enterprises to securely enable application usage using business-relevant concepts, instead of following the traditional approach offered by traditional port-blocking firewalls. Also, special purpose hardware for next generation firewalls (implemented, for example, as dedicated appliances) generally provides higher performance levels for application inspection than software executed on general purpose hardware (e.g., such as security appliances provided by Palo Alto Networks, Inc., which use dedicated, function specific processing that is tightly integrated with a single-pass software engine to maximize network throughput while minimizing latency).
Advanced or next generation firewalls can also be implemented using virtualized firewalls. Examples of such next generation firewalls are commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' VM Series firewalls, which support various commercial virtualized environments, including, for example, VMware® ESXi™ and NSX™, Citrix® Netscaler SDX™, KVM/OpenStack (Centos/RHEL, Ubuntu®), and Amazon Web Services (AWS)). For example, virtualized firewalls can support similar or the exact same next-generation firewall and advanced threat prevention features available in physical form factor appliances, allowing enterprises to safely enable applications flowing into, and across their private, public, and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups, and a REST-based API allow enterprises to proactively monitor VM changes dynamically feeding that context into security policies, thereby eliminating the policy lag that may occur when VMs change.
Examples of such policies include ones governing traffic shaping, quality of service, and routing of traffic. Other examples of policies include security policies such as ones requiring the scanning for threats in incoming (and/or outgoing) email attachments, web site content, files exchanged through instant messaging programs, and/or other file transfers. In some embodiments, data appliance 102 is also configured to enforce policies with respect to traffic that stays within enterprise network 110.
Network 110 also includes a directory service 154 and an Authentication, Authorization, and Accounting (AAA) server 156. In the example shown in
In various embodiments, data appliance 102 is configured to listen to communications (e.g., passively monitor messages) to/from directory service 154 and/or AAA server 156. In various embodiments, data appliance 102 is configured to communicate with (i.e., actively communicate messages with) directory service 154 and/or AAA server 156. In various embodiments, data appliance 102 is configured to communicate with an orchestrator (not pictured) that communicates with (e.g., actively communicates messages with) various network elements such as directory service 154 and/or AAA server 156. Other types of servers can also be included in network 110 and can communicate with data appliance 102 as applicable, and directory service 154 and/or AAA server 156 can also be omitted from network 110 in various embodiments.
While depicted in
Data appliance 102 can be configured to work in cooperation with a remote security platform 140. Security platform 140 can provide a variety of services, including performing static and dynamic analysis on malware samples (e.g., via sample analysis module 124), and providing a list of signatures of known-malicious files, domains, etc., to data appliances, such as data appliance 102 as part of a subscription. As will be described in more detail below, security platform 140 can also provide information (e.g., via IoT module 138) associated with the discovery, classification, management, etc., of IoT devices present within a network such as network 110. In various embodiments, signatures, results of analysis, and/or additional information (e.g., pertaining to samples, applications, domains, etc.) is stored in database 160. In various embodiments, security platform 140 comprises one or more dedicated commercially available hardware servers (e.g., having multi-core processor(s), 32G+ of RAM, gigabit network interface adaptor(s), and hard drive(s)) running typical server-class operating systems (e.g., Linux). Security platform 140 can be implemented across a scalable infrastructure comprising multiple such servers, solid state drives or other storage 158, and/or other applicable high-performance hardware. Security platform 140 can comprise several distributed components, including components provided by one or more third parties. For example, portions or all of security platform 140 can be implemented using the Amazon Elastic Compute Cloud (EC2) and/or Amazon Simple Storage Service (S3). Further, as with data appliance 102, whenever security platform 140 is referred to as performing a task, such as storing data or processing data, it is to be understood that a sub-component or multiple sub-components of security platform 140 (whether individually or in cooperation with third party components) may cooperate to perform that task. As examples, security platform 140 can perform static/dynamic analysis (e.g., via sample analysis module 124) and/or IoT device functionality (e.g., via IoT module 138) in cooperation with one or more virtual machine (VM) servers. An example of a virtual machine server is a physical machine comprising commercially available server-class hardware (e.g., a multi-core processor, 32+ Gigabytes of RAM, and one or more Gigabit network interface adapters) that runs commercially available virtualization software, such as VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Further, a virtual machine server may be under the control of the same entity that administers security platform 140, but may also be provided by a third party. As one example, the virtual machine server can rely on EC2, with the remainder portions of security platform 140 provided by dedicated hardware owned by and under the control of the operator of security platform 140.
An embodiment of a data appliance is shown in
Functionality described herein as being performed by data appliance 102 can be provided/implemented in a variety of ways. For example, data appliance 102 can be a dedicated device or set of devices. A given network environment may include multiple data appliances, each of which may be configured to provide services to a particular portion or portions of a network, may cooperate to provide services to a particular portion or portions of a network, etc. The functionality provided by data appliance 102 can also be integrated into or executed as software on a general purpose computer, a computer server, a gateway, and/or a network/routing device. In some embodiments, at least some functionality described as being provided by data appliance 102 is instead (or in addition) provided to a client device (e.g., client device 104 or client device 106) by software executing on the client device. Functionality described herein as being performed by data appliance 102 can also be performed at least partially by or in cooperation with security platform 140, and/or functionality described herein as being performed by security platform 140 can also be performed at least partially by or in cooperation with data appliance 102, as applicable. As one example, various functionality described as being performed by IoT module 138 can be performed by embodiments of IoT server 134.
Whenever data appliance 102 is described as performing a task, a single component, a subset of components, or all components of data appliance 102 may cooperate to perform the task. Similarly, whenever a component of data appliance 102 is described as performing a task, a subcomponent may perform the task and/or the component may perform the task in conjunction with other components. In various embodiments, portions of data appliance 102 are provided by one or more third parties. Depending on factors such as the amount of computing resources available to data appliance 102, various logical components and/or features of data appliance 102 may be omitted and the techniques described herein adapted accordingly. Similarly, additional logical components/features can be included in embodiments of data appliance 102 as applicable. One example of a component included in data appliance 102 in various embodiments is an application identification engine which is configured to identify an application (e.g., using various application signatures for identifying applications based on packet flow analysis). For example, the application identification engine can determine what type of traffic a session involves, such as Web Browsing—Social Networking; Web Browsing—News; SSH; and so on. Another example of a component included in data appliance 102 in various embodiments is an IoT server 134, described in more detail below. IoT server 134 can take a variety of forms, including as a standalone server (or set of servers), whether physical or virtualized, and can also be collocated with/incorporated into data appliance 102 as applicable (e.g., as shown in
As shown, data appliance 102 comprises a firewall, and includes a management plane 212 and a data plane 214. The management plane is responsible for managing user interactions, such as by providing a user interface for configuring policies and viewing log data. The data plane is responsible for managing data, such as by performing packet processing and session handling.
Network processor 216 is configured to receive packets from client devices, such as client device 108, and provide them to data plane 214 for processing. Whenever flow module 218 identifies packets as being part of a new session, it creates a new session flow. Subsequent packets will be identified as belonging to the session based on a flow lookup. If applicable, SSL decryption is applied by SSL decryption engine 220. Otherwise, processing by SSL decryption engine 220 is omitted. Decryption engine 220 can help data appliance 102 inspect and control SSL/TLS and SSH encrypted traffic, and thus help to stop threats that might otherwise remain hidden in encrypted traffic. Decryption engine 220 can also help prevent sensitive content from leaving enterprise network 110. Decryption can be controlled (e.g., enabled or disabled) selectively based on parameters such as: URL category, traffic source, traffic destination, user, user group, and port. In addition to decryption policies (e.g., that 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 can be required.
Application identification (APP-ID) engine 222 is configured to determine what type of traffic a session involves. As one example, application identification engine 222 can recognize a GET request in received data and conclude that the session requires an HTTP decoder. In some cases, e.g., a web browsing session, the identified application can change, and such changes will be noted by data appliance 102. For example, a user may initially browse to a corporate Wiki (classified based on the URL visited as “Web Browsing—Productivity”) and then subsequently browse to a social networking site (classified based on the URL visited as “Web Browsing—Social Networking”). Different types of protocols have corresponding decoders.
Based on the determination made by application identification engine 222, the packets are sent, by threat engine 224, to an appropriate decoder configured to assemble packets (which may be received out of order) into the correct order, perform tokenization, and extract out information. Threat engine 224 also performs signature matching to determine what should happen to the packet. As needed, SSL encryption engine 226 can re-encrypt decrypted data. Packets are forwarded using a forward module 228 for transmission (e.g., to a destination).
As also shown in
Returning to
Some client devices depicted in
As with commodity computing devices, IoT devices are a target of nefarious individuals. Unfortunately, the presence of IoT devices in a network can present several unique security/administrative challenges. IoT devices are often low-power devices or special purpose devices and are often deployed without the knowledge of network administrators. Even where known to such administrators, it may not be possible to install endpoint protection software or agents on IoT devices. IoT devices may be managed by and communicate solely/directly with third party cloud infrastructure (e.g., with industrial thermometer 152 communicating directly with cloud infrastructure 126) using proprietary (or otherwise non-standard) protocols. This can confound attempts to monitor network traffic in and out of such devices to make decisions about when a threat or attack is happening against the device. Further, some IoT devices (e.g., in a healthcare environment) are mission critical (e.g., a network connected surgical system). Unfortunately, compromise of an IoT device (e.g., by malware 130) or the misapplication of security policies against traffic associated with an IoT device can have potentially catastrophic implications. Using techniques described herein, the security of heterogeneous networks that include IoT devices can be improved and the harms posed to such networks can be reduced.
In various embodiments, data appliance 102 includes an IoT server 134. IoT server 134 is configured to identify IoT devices within a network (e.g., network 110), in some embodiments, in cooperation with IoT module 138 of security platform 140. Such identification can be used, e.g., by data appliance 102, to help make and enforce policies regarding traffic associated with IoT devices, and to enhance the functionality of other elements of network 110 (e.g., providing contextual information to AAA 156). In various embodiments, IoT server 134 incorporates one or more network sensors configured to passively sniff/monitor traffic. One example way to provide such network sensor functionality is as a tap interface or switch mirror port. Other approaches to monitoring traffic can also be used (in addition or instead) as applicable.
In various embodiments, IoT server 134 is configured to provide log or other data (e.g., collected from passively monitoring network 110) to IoT module 138 (e.g., via frontend 142).
One example way of implementing IoT module 138 is using a microservices-based architecture. IoT module 138 can also be implemented using different programming languages, databases, hardware, and software environments, as applicable, and/or as services that are messaging enabled, bounded by contexts, autonomously developed, independently deployable, decentralized, and built and released with automated processes. One task performed by IoT module 138 is to identify IoT devices in the data provided by IoT server 134 (and provided by other embodiments of data appliances such as data appliances 136 and 148) and to provide additional contextual information about those devices (e.g., back to the respective data appliances).
In addition to features built from metadata, a second type of features can be built by IoT module 138 (274), referred to herein as analytics features. An example analytics feature is one built over time based on time-series data, using aggregate data. Analytics features are similarly passed in realtime to analytics engine 272 and stored in feature database 270.
Inline analytics engine 272 receives features on a message bus via a message handler. One task performed is activity classification (278), which attempts to identify activities (such as file download, login/authentication process, or disk backup activity) associated with the session based on the received feature values/session information and attaches any applicable tags. One way of implementing activity classification 278 is via a neural network-based multi-layer perceptron combined with a convolutional neural network.
Suppose, as a result of activity classification, it is determined that a particular device is engaging in printing activities (i.e., using printing protocols) and is also periodically contacting resources owned by HP (e.g., to check for updates by calling an HP URL and using it to report status information). In various embodiments, the classification information is passed to both a clustering process (unsupervised) and a prediction process (supervised). If either process results in a successful classification of the device, the classification is stored in device database 286.
A device can be clustered, by stage one clustering engine 280, into multiple clusters (e.g., acts like a printer, acts like an HP device, etc.) based on its attributes and other behavior patterns. One way of implementing clustering engine 280 is using a gradient boosting framework (e.g., xgb). The stage one classifier can be useful for classifying devices that have not previously been 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).
As shown in
Also shown in
Suppose, as was previously mentioned, Alice was issued a laptop 104 by ACME. Various components of network 110 will cooperate to authenticate Alice's laptop as she uses it to access various resources. As one example, when Alice connects laptop 104 to a wireless access point located within network 110 (not pictured), the wireless access point may communicate (whether directly or indirectly) with AAA server 156 while provisioning network access. As another example, when Alice uses laptop 104 to access her ACME email, laptop 104 may communicate (whether directly or indirectly) with directory service 154 while fetching her inbox, etc. As a commodity laptop running a commodity operating system, laptop 104 is able to generate appropriate AAA messages (e.g., RADIUS client messages) which will help laptop 104 gain access to the appropriate resources it needs.
As previously mentioned, one problem posed by IoT devices (e.g., device 146) in a network such as 110 is that such devices are often “unmanaged” (e.g., not configured, provisioned, managed by network administrators, etc.), do not support protocols such as RADIUS, and thus cannot be integrated with AAA services such as other devices such as laptop 104. A variety of approaches can be adopted to provide IoT devices with network access within network 110, each of which has drawbacks. One option is for ACME to limit IoT devices to use of a guest network (e.g., via a pre-shared key). Unfortunately, this can limit the utility of the IoT device if it is unable to communicate with other nodes within network 110 to which it should legitimately have access. Another option is to allow IoT devices unlimited access to network 110, mitigating the security benefits of having a segmented network. Yet another option is for ACME to manually specify rules that govern how a given IoT device should be able to access resources in network 110. This approach is generally untenable/unworkable for a variety of reasons. As one example, administrators may often not be involved in the deployment of IoT devices and thus will not know that policies for such devices should be included (e.g., in data appliance 102). Even where administrators might, e.g., manually configure policies for specific IoT devices in appliance 102 (e.g., for devices such as device 112), keeping such policies up to date is error prone and is generally untenable given the sheer number of IoT devices that might be present in network 110. Further, such policies will likely be simplistic (e.g., assigning CT scanner 112 by IP address and/or MAC address to a particular network) and not allow for finer grained control over connections/policies involving CT scanner 112 (e.g., dynamically including with policies applicable to surgical devices vs. point of sales terminals). Further, even where CT scanner 112 is manually included in data appliance 102, as previously mentioned, IoT devices will generally not support technologies such as RADIUS, and the benefits in having such AAA servers manage CT scanner 112's networking access will be limited as compared to other types of devices (e.g., laptop 104) which more fully support such technologies. As will be described in more detail below, in various embodiments, data appliance 102 (e.g., via IoT server 134) is configured to provide support for AAA functionality to IoT devices present in network 110 in a passive manner.
In the following discussion, suppose that Alice's department in ACME has recently purchased an interactive whiteboard 146 so that Alice can collaborate with other ACME employees as well as individuals outside of ACME (e.g., Bob, a researcher at Beta University having its own network 114, data appliance 136, and whiteboard 144). As part of the initial setup of whiteboard 146, Alice connects it to a power source and provides it with a wired connection (e.g., to an outlet in the conference room) or wireless credentials (e.g., the credentials for use by visitors of the conference room). When whiteboard 146 provisions a network connection, IoT server 134 (e.g., via a mechanism such as a network sensor as described above) will recognize whiteboard 146 as a new device within network 110. One action taken in response to this detection is to communicate with security platform 140 (e.g., creating a new record for whiteboard 146 in database 160 and retrieving any currently available contextual information associated with whiteboard 146 (e.g., obtaining the manufacturer of whiteboard 146, model of whiteboard 146, etc.)). Any contextual information provided by security platform 140 can be provided to (and stored at) data appliance 102 which can in turn provide it to directory service 154 and/or AAA server 156 as applicable. As applicable, IoT module 138 can provide updated contextual information about whiteboard 146 to data appliance 102 as it becomes available. And, data appliance 102 (e.g., via IoT server 134) can similarly provide security platform 140 with ongoing information about whiteboard 146. Examples of such information include observations about whiteboard 146's behaviors on network 110 (e.g., statistical information about the connections it makes) which can be used by security platform 140 to build behavioral profiles for devices such as whiteboard 146. Similar behavior profiles can be built by security platform 140 for other devices (e.g., whiteboard 144). Such profiles can be used for a variety of purposes, including detecting anomalous behaviors. As one example, data appliance 148 can use information provided by security platform 140 to detect whether thermometer 152 is operating anomalously as compared to historic observations of thermometer 152, and/or as compared to other thermometers (not pictured) of similar model, manufacturer, or more generally, including thermometers present in other networks. If anomalous behavior is detected (e.g., by data appliance 148), appropriate remedial action can be automatically taken, such as restricting thermometer 152's access to other nodes on network 116, generating an alert, etc.
As discussed above, security platform 140 maintains (e.g., in database 160) various information usable to identify different types of IoT devices. Some devices (e.g., commodity consumer-oriented products) will make use of common protocols/applications and can be readily identified (e.g., by security platform 140) using such information. Examples of such devices include printers, cameras, thermostats, and cleaning robots. As another example, radiology devices typically use a well-documented non-proprietary data interchange protocol known as Digital Imaging and Communications in Medicine (DICOM). In various embodiments, IoT server 134 (or another element, as applicable) includes a DICOM decoder that can decode DICOM traffic and extract various attributes (e.g., manufacturer identifier, version of the DICOM implementation, etc.) that are usable in identifying a given radiology device.
Unfortunately, some IoT devices use proprietary technologies, such as proprietary networking protocols and/or applications, which can make identification more challenging. Examples of such devices in the healthcare vertical include patient monitors, nurse call systems, medication dispensing systems, vital signs monitors, and telemedicine robots. Examples of such devices in the industrial and manufacturing verticals include programmable logic controllers, automatic guided vehicles, semiconductor manufacturing equipment, and robotic arms. While some specialized devices may use standard protocols and/or applications, others may use protocols that are not understood by security platform 140. In various embodiments, security platform 140 can nonetheless classify such devices, and allow data appliances such as data appliance 102 to enforce policies with respect to such devices.
A given byte of network traffic (comprising eight bits) has a value from 0 to 255. Different types of devices use different applications, which will often have unique sets of frequently used bytes. In some cases, information about byte frequency can be used to distinguish the traffic of different types of devices, without having to understand the underlying meaning of the traffic.
Each application executing on a device has a corresponding flow that can be observed by a data appliance (e.g., a TCP flow or UDP flow observed by data appliance 102). In an example embodiment, for each flow, IoT server 134 keeps track of the bytes in the payload (e.g., incrementing an applicable count for each of bytes 0-255 in an array) as they are observed. An example way of storing such data is as a 2-dimensional array (for each device) where the first dimension is a flow identifier and the second dimension is a byte value 0-255. At the transport layer, a flow can be uniquely identified by a 5-tuple: <src_ip, src_port, dst_ip, dst_port, prot>, where src_ip is the source IP address, src_port is the source port number, dst_ip is the destination IP address, dst_port is the destination port number, and prot is the protocol number. A hash table can be used to map each unique 5-tuple to an integer flow identifier. When a packet arrives, the 5-tuple in its transport layer header is used to look up the hash table to find the flow identifier if it exists, or create a new one otherwise. After determining the flow identifier, the corresponding byte frequencies are updated based on the payload in the packet (as illustrated in
In some embodiments, the raw byte counts are reported (e.g., by IoT server 134) to security platform 140 (along with, e.g., a MAC address of the device and other information). An example of such a report (in the JSON format) is shown in
At 704, the received pattern is used to determine a classification for the IoT device. A variety of approaches can be used to perform this determination. As a first example, the pattern can be compared against a library of previously determined patterns (e.g., profiles stored in database 160 and generated from observations of known devices). If the received pattern matches a previously stored profile within a threshold amount, the IoT device can be classified accordingly. Accuracy can be improved by considering multiple features. As an example, any available static features (such as an organizationally unique identifier (OUI)) can be considered when determining whether the received BFD matches a previously stored library profile. In this scenario, for example, a device would only be classified at 704 as being a particular brand of infusion pump if both the BFD matches a library profile within a threshold amount and the OUI of the device matches the OUI associated with the library profile. Further, portions 702/704 of process 700 can occur multiple times. For example, when a device is first added to a network, it may take some time (e.g., hours or days) before the device makes comprehensive use of its application(s) and its byte frequency pattern is representative of its communications. If no classification match is initially found at 704, the process can be periodically repeated with updated BFDs.
In various embodiments, a machine-learning approach is used at 704. As an example, in some embodiments, IoT module 138 includes a machine learning device identification engine that uses a Feedforward Neural Network for multi-class classification. It supports both supervised learning for profile-level device identification, as well as unsupervised learning that classifies devices into different categories for further study. In the supervised learning case, labeled data (i.e., known profile of devices and their corresponding features) is provided to train the model. Then the model predicts the profile of new devices based on their features (including 256 features corresponding to each byte frequency percentage). The following are examples of additional features that can be extracted from network traffic metadata and included in the modeling: total bytes, total packets, total sessions, total session durations, server port numbers, application list, encrypted bytes, remote IP list, download payload bytes, HTTP request count, HTTP response count, TCP SYN count, and TCP ACK count. In the unsupervised learning case, devices are classified into categories with unknown profiles based on their features. If further study reveals the profile-level identity of a device in a category, that information can be used to identify all devices in the same category.
Finally, at 706 the classification determined at 704 is provided to a security appliance configured to apply a policy to the IoT device. As mentioned above, this allows for highly fine-grained security policies to be implemented in potentially mission critical environments with minimal administrative effort. As applicable, security platform 140 can recommend particular policies based on the classification determined at 704. The following are examples of policies that can be enforced:
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
This application claims priority to U.S. Provisional Patent Application No. 63/033,012 entitled IOT DEVICE CLASSIFICATION USING STATISTICAL FINGERPRINTS IN NETWORK TRAFFIC filed Jun. 1, 2020 which is incorporated herein by reference for all purposes.
Number | Name | Date | Kind |
---|---|---|---|
7624446 | Wilhelm | Nov 2009 | B1 |
20040039806 | Miras | Feb 2004 | A1 |
20100192225 | Ma | Jul 2010 | A1 |
20160212099 | Zou | Jul 2016 | A1 |
20180139141 | Stepanek | May 2018 | A1 |
20190222594 | Davis, III | Jul 2019 | A1 |
20190394305 | Kim | Dec 2019 | A1 |
20200120004 | Kohout | Apr 2020 | A1 |
Number | Date | Country |
---|---|---|
102891796 | Jan 2013 | CN |
104079450 | Oct 2014 | CN |
2007074339 | Mar 2007 | JP |
20190046018 | Oct 2017 | KR |
Number | Date | Country | |
---|---|---|---|
20210377215 A1 | Dec 2021 | US |
Number | Date | Country | |
---|---|---|---|
63033012 | Jun 2020 | US |