Increased coverage for application-based traffic classification using local and cloud classification services

Abstract

The cloud-based traffic classification engine maintains a catalog of application-based traffic classes developed based on known applications, and the local traffic classification engine maintains a subset of these classes. Network traffic intercepted by the firewall that cannot be classified by the local engine is forwarded to the cloud-based engine for classification. Upon determining the class of the traffic, the cloud-based engine forwards the determined class and corresponding signature to the local engine. The firewall maintains a cache that is updated with signatures corresponding to the classes communicated by the cloud-based engine. Subsequent network traffic sent from the application may be determined to correspond to the application and classified locally at the firewall based on the cached signature. The cache local to the firewall reduces the latency of traffic classification operations as the catalog of classification information stored in the cloud scales.

Description

[Technical Field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates generally to the transmission of digital information and to network architectures or network communication protocols for network security.

[0002] As part of enforcing security policies, firewalls perform traffic classification. Firewalls typically classify network traffic based on ports, network protocols, or a combination thereof. Firewalls may also perform deep packet inspection, or packet sniffing, as part of classifying network traffic. Deep packet inspection examines the contents of network packets, thus facilitating content-based classification of network traffic based on matching signatures generated from data communicated via the network packets. [Brief explanation of the drawings]

[0003] Embodiments of the present disclosure may be better understood with reference to the accompanying drawings. [Figure 1] Figure 1 shows a conceptual diagram of combining local and cloud-based traffic classification for low-latency classification of network traffic by application. [Figure 2] Figure 2 shows a conceptual diagram of the automated collection of unclassified network traffic for application signature creation. [Figure 3] FIG. 3 is a flow chart of one exemplary operation for classifying detected network traffic by application. [Figure 4]FIG. 4 is a flow chart of one exemplary operation for classifying detected network traffic by application. [Figure 5] FIG. 5 is a flow chart of one exemplary operation for classifying packets forwarded from a firewall into classes representing applications. [Figure 6] FIG. 6 illustrates an exemplary computer system having a local traffic classification engine and a cloud-based traffic classification engine. [Figure 7] FIG. 7 is a flow chart of one exemplary operation for classifying detected network traffic by application. [Figure 8] FIG. 8 is a flowchart of one exemplary operation for performing cloud-based classification of network traffic by an application. [Figure 9] FIG. 9 is a flowchart of one exemplary operation for determining an application associated with detected network traffic and classifying the network traffic accordingly. DETAILED DESCRIPTION OF THE INVENTION

[0004] The following description includes example systems, methods, techniques, and program flows that embody aspects of the present disclosure. However, it will be understood that the present disclosure may be practiced without these specific details. In other instances, well-known instruction sets, protocols, structures, and techniques have not been shown in detail so as not to obscure the description.

[0005] overview

[0006] A firewall-based traffic classification engine analyzes network traffic based on classification information stored locally on the firewall to classify the network traffic by application. Network traffic can be classified by application based on evaluating the network traffic against signatures representing the applications and classifying the network traffic into classes corresponding to the applications represented by a matching signature. While local traffic classification services provide application-based policy enforcement regardless of whether detection evasion techniques are implemented, the number of signatures that can be stored locally and leveraged with this approach, as well as the ability to scale up as new signatures are created, are limited due to firewall hardware limitations.

[0007] Disclosed herein is a technique for extending the coverage of a traffic classification service using a combination of functionality provided by a traffic classification engine running locally on the firewall and a cloud-based traffic classification engine running in the cloud. The cloud-based engine maintains a catalog of applications and corresponding signatures that have been developed with which it can classify network traffic, and the local engine maintains a subset of this catalog that can represent the most commonly used or frequently accessed applications. Network traffic intercepted by the firewall that cannot be classified by application based on information locally available to the local engine is forwarded to the cloud-based engine for classification based on the larger catalog of applications with which it can classify the network traffic. After classifying the traffic into classes representing the applications based on signature matching, the cloud-based engine forwards the determined classes, indicating the corresponding applications and matching signatures, to the local engine. The firewall maintains a cache that is updated with signatures and instructions for corresponding applications communicated by the cloud-based engine that were not included in the classification information originally installed on the firewall. Subsequent network traffic exchanged during a session involving an application represented by the class can be classified accordingly by the local engine based on the cached signature. Localizing the cache to the firewall through caching of signatures determined based on the network traffic it intercepts reduces the latency of local traffic classification operations even as the catalog of classification information stored in the cloud scales up.Additionally, extending traffic classification to the cloud, where a catalog of classification information is maintained, increases the range of applications according to which network traffic can be classified, thus reducing the amount of network traffic that passes as unknown traffic and improving the enforcement of application-based security policies at firewalls.

[0008] Network traffic for applications for which signatures have not yet been determined and therefore cannot be classified by the local or cloud-based engine may be forwarded by the cloud-based engine to a signature creation service. Because application signature creation is traditionally accomplished through manual efforts involving setting up an application environment and capturing network traffic, eliminating this step by automatically forwarding detected network traffic directly to a signature creation service reduces the costs and associated challenges involved in manual research and development for the creation of new signatures.

[0009] Illustrative Description

[0010] FIG. 1 shows a conceptual diagram of combining local and cloud-based traffic classification for low-latency classification of network traffic by application. Firewall 129 monitors and controls incoming and outgoing network traffic across network 127 for client 101. A local traffic classification engine (“local engine”) 103 running as part of firewall 129 classifies detected network traffic by corresponding application. A cloud-based traffic classification engine (“cloud-based engine”) 107 runs within cloud 117. For example, cloud-based engine 107 may run on one or more nodes (e.g., physical machines and / or virtual machines) available in cloud 117. Firewall 129 maintains an application class cache (“cache”) 105 that stores traffic classification information communicated from cloud-based engine 107 to local engine 103.

[0011] Figure 1 is annotated with a series of letters A-F. These letters represent stages of operation. Although these stages are ordered for this example, they represent an example to aid in understanding the disclosure and should not be used to limit the claims. Subject matter encompassed within the scope of the claims may vary with respect to the order and some of the operations.

[0012] In phase A, firewall 129 detects a session initiated by client 101 with server 109, which maintains resources for an application named "eMarket." The application "eMarket" may be a web application running on server 109, to which client 101 requests access. Firewall 129 detects packet 121 sent from server 109 to client 101. Detection of network traffic sent between client 101 and server 109 triggers local engine 103 to evaluate packet 121 and / or the request issued by client 101 and classify the network traffic by application so that security policies specifying the appropriate application can be applied.

[0013] In phase B, local engine 103 evaluates packet 121 and determines whether packet 121 can be classified into an application class. Local engine 103 maintains application classes 123, which include classes of network traffic representing applications. Each class of network traffic defined in application classes 123 representing an application is also associated with a signature for packets of that application. The signatures included within application classes 123 include application signatures and / or context-based signatures that are applied as part of packet decoding. Local engine 103 determines whether packet 121 can be classified into one of application classes 123 based on evaluating the signatures of application classes 123 against packet 121 to determine whether one of the signatures matches packet 121. Local engine 103 also reads a signature corresponding to the application class from cache 105 and evaluates the read signature against packet 121 to determine whether the cached signature matches packet 121 and therefore can classify packet 121 into the corresponding application class. Local engine 103 in this example determines that packet 121 cannot be classified into application class 123 and one of the classes maintained locally in cache 105. That is, neither application class 123 nor cache 105 contains an application class and associated signature representing an application named "eMarket."

[0014] In stage C, local engine 103 forwards at least packet 121A of packets 121 to cloud-based engine 107 for classification. Local engine 103 can forward all, a subset, or one of packets 121 to cloud-based engine 107 as specified by packet-forwarding policy 125. Packet-forwarding policy 125 can also indicate which portion of the payload local engine 103 should forward to cloud-based engine 107 (e.g., based on an offset value, a particular field of the packet, etc.). Packets that are initially unclassified by local engine 103 are forwarded to cloud-based engine 107 for further evaluation based on application class catalog (“catalog”) 115. Catalog 115 includes an extensive set of defined application classes and corresponding application signatures, context-based signatures, etc. The application classes 123 accessed locally by the local engine 103 comprise a subset of the application classes stored in the catalog 115, and thus forwarding a packet that is not classified into one of the application classes 123 to the cloud-based engine 107 expands the range of applications to which the packet can be classified.

[0015] In stage D, cloud-based engine 107 evaluates packet 121A and determines whether packet 121A can be classified into one of the application classes contained in catalog 115. For example, cloud-based engine 107 may evaluate packet 121A against signatures associated with application classes stored in the catalog to determine whether a match can be identified. In this example, a signature representing application "eMarket" is not included in application class 123 but is included in catalog 115. Cloud-based engine 107 therefore determines that packet 121A can be classified into the application class corresponding to application "eMarket" based on applying the signatures included in catalog 115 and determining that signature 119 representing application "eMarket" matches packet 121A.

[0016] In stage E, cloud-based engine 107 communicates to local engine 103 an indication of the application class representing application "eMarket" and corresponding signature 119. Local engine 103 obtains signature 119 and the indication of the application class corresponding to application "eMarket" from cloud-based engine 107 and classifies packet 121 into the application class for "eMarket." As part of classifying packet 121, local engine 103 may associate a session ID of the session between client 101 and server 109 with the indication of the application class into which packet 121 was classified, such that packet 121 and any subsequent packets communicated during the session are associated with the application class representing application "eMarket." By classifying packet 121 into an application-based traffic class, firewall 129 can subsequently apply fine-grained policies specifically defined for the application class corresponding to application "eMarket."

[0017] In phase F, local engine 103 updates cache 105 with the application class indication and signature 119 communicated from the cloud-based engine. Local engine 103 writes signature 119 and the corresponding application class defined for application "eMarket" to cache 105. Upon detecting a packet sent as part of a subsequent session between client 101 and server 109 to access content for application "eMarket," local engine 103 can retrieve signature 119 from cache 105 and locally classify the packet into the appropriate application class based on evaluating packets exchanged during the session against signature 119, rather than sending the packet to cloud-based engine 107 for classification.

[0018] Figure 2 shows a conceptual diagram of the automated collection of unclassified network traffic for application signature creation. Collecting application network traffic for application signature creation is traditionally a laborious manual process, but the local engine 103 and cloud-based engine 107 can be used to automate this network traffic collection. Figure 2 shows an example in which the local engine 103 and cloud-based engine 107 determine whether packets 221 of a session between a client 101 and a server 209 that hosts resources for an application named "vstream" can be classified into an application class.

[0019] Local engine 103 sends at least packet 221A of packets 221 specified by packet forwarding policy 125 to cloud-based engine 107. Local engine 103 determines that packet 221 cannot be classified into application class 123 or one of the application classes for which a signature is read from cache 105, as also described with reference to FIG. 1 . Cloud-based engine 107 then determines that packet 221A cannot be classified into one of the application classes included in catalog 115. For example, a signature representing application “vstream” may not yet have been created and inserted into catalog 115. Cloud-based engine 107 communicates to local engine 103 that packet 221 should be classified as unknown traffic, and firewall 129 policy is applied accordingly.

[0020] Based on a determination that packet 221A could not be classified into an application class in catalog 115, cloud-based engine 107 designates packet 221A for application signature creation by forwarding packet 221A to signature creation service 211. Signature creation service 211 may run on a server external to cloud 217 and firewall 219. Cloud-based engine 107 may send additional packets of packet 221 (e.g., in addition to packet 221A) to signature creation service 211 for storage in collected packet repository 213. Cloud-based engine 107 may include additional identifying information of packet 221, such as source address, destination address, port number, and / or network protocol, in its communication to signature creation service 211 so that similar packets that would be classified into the same application class can be grouped for signature creation. Forwarding packet 221 to signature creation service 211 allows a signature for the application named "vstream" to be later created. Later, once an application signature representing the application "vstream" is created, the signature and an indication of the application class corresponding to "vstream" can be inserted into catalog 115 and / or application class 123. As a result, local engine 103 and cloud-based engine 107 can later classify detections into the application class representing "vstream."

[0021] 3-5 are flowcharts of example operations for increasing application-based traffic classification coverage by utilizing local and cloud-based traffic classification engines. The example operations are described with reference to a local traffic classification engine (hereinafter, "local engine") and a cloud-based traffic classification engine (hereinafter, "cloud engine") for consistency with previous figures. The names chosen for the program code do not limit the scope of the claims. The structure and organization of the program may vary depending on the platform, programmer / architect preferences, programming language, etc. Additionally, the names of the code units (programs, modules, methods, functions, etc.) may vary and be arbitrary for the same reasons.

[0022] 3-4 are flowcharts illustrating an example operation for classifying detected network traffic by application. The example operation in FIG. 3 is performed by a local engine, which may run as part of a firewall. In block 301, the local engine detects network traffic for a session. The network traffic may be a request to access an application issued from a client initiating a session to a server, data sent from the server to the client in response, a combination thereof, etc.

[0023] In block 302, the local engine applies a set of available signatures from a catalog of signatures representing applications to the network traffic. Applying a set of signatures to the network traffic refers to evaluating the signatures against the network traffic to determine whether a matching signature can be found. The catalog of signatures includes a representation of a plurality of applications by which the network traffic may be classified, and a plurality of signatures, such as application signatures and / or protocol-based signatures, representing corresponding applications among the plurality of applications. Each signature representing an application may be used as a criterion for classifying network traffic into a class corresponding to that application. The set of signatures available to the local engine is a subset of this catalog of locally accessible signatures and may be signatures representing the most popular or commonly accessed applications. The set of signatures applied to the network traffic may also include signatures retrieved from a signature cache maintained for the firewall. The local engine may apply the set of signatures, or different subsets thereof, at one or more stages of classifying network traffic. For example, the local engine may apply application communication protocols to the network traffic at a first stage, and then, at a second stage, apply additional signatures corresponding to signatures associated with the network traffic as part of traffic decoding (e.g., signatures for Hypertext Transfer Protocol (HTTP) traffic, File Transfer Protocol (FTP) traffic, etc.).

[0024] In block 303, the local engine determines whether a matching signature is found as a result of applying the set of signatures to the network traffic. The local engine determines whether the network traffic matches a first one of the signatures. Identifying a matching signature contributes to classifying the network traffic into a class corresponding to the application having the matching signature. If a match is found, operations continue to block 304. If a match is not found, operations continue to block 305.

[0025] At block 304, the local engine classifies the network traffic for the session into an application-based class that corresponds to the matching signature. The application-based class may correspond to a particular application or a group of applications (e.g., applications belonging to an application suite). Classifying the network traffic may include the local engine associating a session ID for the session with an indication of the class to which the network traffic has been classified. As a result, subsequent packets detected during the session are also associated with the determined class. Security policies specifically defined for the application may be applied to the network traffic and any network traffic subsequently detected during the session. Operation continues to transition point A, which is continued from transition point A in FIG. 4.

[0026] At block 305, the local engine determines whether similar network traffic was previously classified as unknown traffic. The local engine may maintain an indication of network traffic classified as unknown traffic based on previous local and cloud-based classifications, reducing repeated uploads to the cloud of unknown network traffic with the same characteristics and, therefore, reducing costs. For example, the indication of unknown traffic may include a combination of source address, destination address, port number, and / or network protocol associated with the unknown network traffic and may be stored in an additional cache maintained for the firewall. The local engine may evaluate network traffic metadata (e.g., based on the network traffic header) against the indication of unknown network traffic to determine whether previously detected network traffic having the same combination of source address, destination address, port number, and / or network protocol was classified as unknown traffic. If the similar network traffic has not been classified as unknown, operations continue to block 306. If the similar network traffic has been classified as unknown, operations continue to transition point B, which is shown in FIG. 4.

[0027] In block 306, the local engine forwards one or more packets of the network traffic to the cloud-based service for classification. A policy attached to (e.g., installed or otherwise accessible to) the local engine can dictate the portion of the network traffic to be forwarded / uploaded to the cloud-based service. For example, the policy can dictate whether a detected packet or each detected packet comprising the network traffic should be forwarded to the cloud-based service. The policy can also indicate the portion of the packet that should be forwarded to the cloud. As one example, the policy can indicate that the entire payload or a predetermined portion of the payload should be forwarded. Operations performed by the cloud-based service based on receiving the forwarded network traffic from the local engine are described with reference to FIG. 5. Operations continue to transition point C, which follows transition point C of FIG. 4.

[0028] At block 407, the local engine determines whether the network traffic can be classified by an application. The local engine determines whether the network traffic can be classified into a class corresponding to the application based on obtaining an indication from the cloud-based service regarding how the forwarded packet can be classified. If the forwarded packet can be classified by the application, the local engine may obtain an indication of a class representing the application and corresponding signature that the forwarded packet matched. If the forwarded packet cannot be classified by the application, the local engine may obtain an indication from the cloud-based service that the forwarded packet can be classified as unknown traffic. If the network traffic can be classified into a traffic class representing the application, operations continue to block 409. If the network traffic cannot be classified into a traffic class representing the application, operations proceed to block 413.

[0029] In block 409, the local engine updates its set of signatures with the signature and class indication communicated from the cloud-based service. For example, the local engine can write the signatures and corresponding application indications communicated from the cloud-based service in block 407 to a signature cache so that the signatures can be accessed locally for subsequent traffic classification events. The signatures written to the cache can be content-based signatures and / or context-based signatures representing the applications. The class indication can be a class name, identifier (ID), etc., which can correspond to the name, ID, etc. of the application that the class represents. Later, once network traffic is subsequently detected during a different session that includes the application, the local engine can read the signature from the cache and classify the network traffic accordingly in block 303 instead of forwarding the network traffic to the cloud-based service for classification.

[0030] In block 411, the local engine associates an indication of the class with the session. For example, the local engine may associate a class name, ID, etc. with a session ID for a session maintained by the local engine. Associating an indication of the traffic class with the session effectively categorizes network traffic communicated as part of a session having that session ID into a class. Based on the class designation, application-specific defined security policies can then be applied to the session's network traffic.

[0031] The local engine classifies the network traffic into a class of unknown traffic in block 413. The local engine can associate a name, ID, etc. used for the unknown traffic class with the session (e.g., the session ID of the session) so that any network traffic exchanged during the session can be treated as unknown traffic, and corresponding security policies defined for unknown traffic can be applied.

[0032] In block 415, the local engine updates the maintained indication of unknown traffic with the network traffic metadata. The local engine may add new entries to the indication of unknown traffic (e.g., write new entries to a cache) indicating source addresses, destination addresses, port numbers, and / or network protocols associated with the network traffic, which may be determined based on the headers of the network traffic and based on decoding the network traffic. Subsequent detected network traffic associated with a similar combination of these metadata may be identified in block 305 as likely unknown.

[0033] 5 is a flow chart of one exemplary operation for classifying packets forwarded from a firewall into classes representing applications. The exemplary operation in FIG. 5 is performed by a cloud-based engine running in the cloud. The exemplary operation assumes that one or more unclassified packets have been forwarded from a local engine running on the firewall, as described with reference to FIG. 3.

[0034] In block 501, the cloud-based engine captures one or more packets detected by and forwarded from the firewall. Each captured packet may include a header and a payload or a designated portion of the payload. The portion of the packet (e.g., the portion of the payload) that is forwarded to the cloud-based engine may be defined by a policy stored on the firewall.

[0035] In block 503, the cloud-based engine applies a signature from a signature catalog to the packet to determine whether the packet can be classified into a class representing the application. The cloud-based engine can maintain a representation of multiple classes corresponding to applications and a corresponding plurality of criteria for classifying packets into each class. The criteria for classifying a packet into a class indicate a signature from the signature catalog representing the same application as the class, and if a signature indicated in the criteria matches the packet, the packet is classified into that class. The signature catalog includes signatures such as application signatures and context-based signatures that are applied using decoders for known network protocols predefined based on network traffic sent to / from the application. The signature catalog stored in the cloud can be distinguished from signatures stored in the firewall where the packet is initially evaluated in that the signatures stored in the firewall are a subset of the signatures in the signature catalog. If a signature is known or defined for the application associated with the session during which the packet was detected, applying the signature from the signature catalog results in a match so that the packet can be classified into the corresponding class.

[0036] In block 505, the cloud-based engine determines whether the packet can be classified into one of the classes based on the signature matching. The packet can be classified into a class if one of the signatures in the signature catalog matches the packet. If the packet can be classified into a traffic class, operations continue to block 507. If the packet cannot be classified into a traffic class, operations continue to block 509.

[0037] In block 507, the cloud-based engine communicates to the firewall an indication of the class of the packet and the matching signature. The class of the packet is the class corresponding to the signature that the packet matched. The indication of the class may be the name, ID, etc. of the class or the application it represents. The signature communicated to the firewall is the signature that the packet matched.

[0038] In block 509, the cloud-based engine determines whether the packet can be classified into a generic traffic class. A generic traffic class represents a class of applications that share common characteristics, such as "web-browsing" for browser-based applications or "unknown_TCP" for applications that use unknown Transmission Control Protocol (TCP) ports. The cloud-based engine can evaluate the packet based on a set of generic traffic classes and corresponding criteria for classifying the packet into one of the generic traffic classes. Here, the criteria may indicate one or more characteristics that must be exhibited by the packet header and / or payload to be classified into the corresponding generic traffic class. The cloud-based engine evaluates the packet against these criteria to determine whether one of the criteria is satisfied. If the packet can be classified into a generic traffic class, operations continue to block 511. If the packet cannot be classified into a generic traffic class, operations continue to block 513.

[0039] In block 511, the cloud-based engine communicates an indication of the generic traffic class to the firewall. The cloud-based engine communicates the name, ID, etc. of the generic traffic class to the firewall. Although generic classes do not have corresponding signatures defined for known applications, the generic class into which a packet is classified allows the firewall to enforce security policies defined at the level of the generic class of application rather than security policies defined at the level of port numbers and / or network protocols.

[0040] In block 513, the cloud-based engine designates the packet for signature creation. Designating the packet for signature creation may include, for example, sending the packet to an external server where packets that could not be classified are stored. The cloud-based engine may also associate port numbers, source addresses, destination addresses, and / or network protocols extracted from the packet header or traffic decoding with the packet, thereby distinguishing the packets so that similar traffic can be aggregated for creation of common signatures and traffic classes. + can be done.

[0041] In block 515, the cloud-based engine communicates to the firewall that the packet cannot be classified by application. The communication to the firewall can indicate that the packet cannot be classified into any of the classes corresponding to the application, or that the packet can be classified as unknown traffic. Packets detected during the session can therefore be treated as unknown traffic for purposes of applying firewall policies.

[0042] Variations

[0043] The flowcharts are provided to aid in understanding the examples and should not be used to limit the scope of the claims. The flowcharts illustrate example operations that may vary within the scope of the claims. Additional operations may be performed, fewer operations may be performed, operations may be performed in parallel, and operations may be performed in a different order. For example, the operations shown in blocks 413 and 415 may be performed in parallel or simultaneously. It will be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, may be implemented by program code. The program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable machine or device.

[0044] As will be appreciated, aspects of the present disclosure may be embodied as a system, method, or program code / instructions stored on one or more machine-readable media. Accordingly, aspects may take the form of hardware, software (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, all of which may be generally referred to herein as a "circuit," "module," or "system." Functionality presented as individual modules / units in the exemplary diagrams may be organized differently according to any one of platform (operating system and / or hardware), application ecosystem, interface, programmer preference, programming language, administrator preference, etc.

[0045] Any combination of one or more machine-readable media may be utilized. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable storage medium may be, for example, but not limited to, a system, apparatus, or device employing any one or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technologies to store program code. More specific examples (non-exhaustive list) of machine-readable storage media include: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the context of this specification, a machine-readable storage medium may be any tangible medium that contains or can store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable storage medium is not a machine-readable signal medium.

[0046] A machine-readable signal medium may include a propagated data signal with machine-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A machine-readable signal medium is not a machine-readable storage medium but may be any machine-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0047] The program code embodied on the machine-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0048] The program code / instructions may also be stored on a machine-readable medium that can instruct a machine to function in a particular manner, such that the instructions stored on the machine-readable medium create a product including instructions that implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0049] FIG. 6 illustrates an exemplary computer system having a local traffic classification engine and a cloud-based traffic classification engine. The computer system includes a processor 601 (possibly including multiple processors, multiple cores, multiple nodes, and / or implementing multithreading, etc.). The computer system includes a memory 607. The memory 607 may be system memory or any one or more of the possible implementations of a machine-readable medium described above. The computer system also includes a bus 603 and a network interface 605. The system also includes a local traffic classification engine 611 and a cloud-based traffic classification engine 613. The local traffic classification engine 611 analyzes network traffic to classify it based on associated applications and forwards unknown network traffic to the cloud-based traffic classification engine 613 for identification. The cloud-based traffic classification engine 613 classifies the network traffic forwarded by the local application identification engine 611 based on associated applications by leveraging a more extensive catalog of network traffic classes than is available to the local traffic classification engine 611. The local traffic classification engine 611 and the cloud-based traffic classification engine 613 do not necessarily execute on the same computer system. For example, the local traffic classification engine 611 may execute on a firewall, and the cloud-based traffic classification engine 613 may execute in the cloud. Any one of the foregoing functions may be implemented partially (or entirely) in hardware and / or in the processor 601. For example, the functions may be implemented using an application-specific integrated circuit, in logic implemented within the processor 601, in a co-processor on a peripheral device or card, etc.Additionally, implementations may include fewer or additional components (e.g., a video card, an audio card, additional network interfaces, peripheral devices, etc.) not shown in Figure 6. Processor 601 and network interface 605 are coupled to bus 603. Although shown as coupled to bus 603, memory 607 may be coupled to processor 601.

[0050] While the above adequately describes exemplary embodiments, language is somewhat limiting when describing innovations. Furthermore, regional and national intellectual property (IP) offices have varying requirements. The following description and corresponding flowcharts attempt to disclose the technology in slightly different language, taking into account the language constraints and requirements of the numerous national / regional IP offices. The phrase "executing program code" refers to program code executing on any of numerous executing implementations, such as a computer, a security appliance, a virtual machine, or a cloud-based service.

[0051] 7 is a flowchart of one example operation for classifying detected network traffic by application. At block 701, executing program code of a cybersecurity device (e.g., a firewall) detects a set of one or more packets communicated during a first session. At block 703, executing program code of the cybersecurity device determines whether the application can be identified based, at least in part, on a set of signatures maintained by the cybersecurity device. At block 705, based on determining that the application cannot be identified based on the set of signatures maintained by the cybersecurity device, executing program code of the cybersecurity device forwards at least a first packet of the set of packets to a cloud-based service. At block 707, executing program code of the cloud-based service determines whether the application can be identified based, at least in part, on the first packet and a plurality of signatures maintained in a cloud in which the cloud-based service executes, where the plurality of signatures includes a set of signatures. Based on determining that the application can be identified at block 709, executing program code of the cloud-based service communicates to the cybersecurity device an indication of the application and a first signature of the plurality of signatures associated with packets of the application. At block 711, executing program code of the cybersecurity device receives the indication of the application and the first signature.

[0052] 8 is a flowchart of an example operation for performing cloud-based classification of network traffic by an application. At block 801, executing program code detects network traffic of a first session. At block 803, executing program code determines whether the network traffic can be classified into one of a set of application classes. At block 805, based on a determination that the network traffic cannot be classified into one of the set of application classes, executing program code communicates one or more packets of the network traffic to a cloud-based service. At block 807, based on obtaining from the cloud-based service an indication of the first application class and a first signature associated with the communicated one or more packets, executing program code associates the indication of the first application class with an identifier of the first session, where the first application class was not included in the set of application classes. At block 809, executing program code updates the set of application classes with the first application class.

[0053] 9 is a flowchart of one example operation for determining an application associated with detected network traffic and classifying the network traffic accordingly. At block 901, executing program code obtains a first packet that could not be classified by a cybersecurity device. At block 903, executing program code evaluates the first packet against a plurality of application signatures to classify the first packet, where the plurality of application signatures represent a plurality of applications. At block 905, based on matching the first packet with one of the plurality of application signatures, executing program code classifies the first packet into an application class of one of the plurality of applications represented by the matching application signature. At block 907, the executing program code communicates the application class into which the first packet was classified and the matching application signature to the cybersecurity device.

[0054] While aspects of the present disclosure are described with reference to various implementations and uses, it will be understood that these aspects are exemplary and that the claims are not limited thereto. In general, the techniques for increasing the coverage of application-based traffic classification and policy enforcement by extending the scope of traffic classification services as described herein may be implemented using equipment consistent with any one or more hardware systems. Many variations, modifications, additions, and improvements are possible.

[0055] Multiple instances may be provided of components, operations, or structures described herein as a single instance. Finally, boundaries between various components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific exemplary configurations. Other allocations of functionality are contemplated and may be included within the scope of the present disclosure. In general, structures and functions presented as separate components in exemplary configurations may be implemented as combined structures or components. Similarly, structures and functions presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may be included within the scope of the present disclosure.

[0056] term

[0057] This specification uses shorthand terms related to cloud technology for efficiency and ease of explanation. When referring to a "cloud," the description is referring to a cloud service provider's resources. For example, a cloud can encompass a cloud service provider's servers, virtual machines, and storage devices. The terms "cloud destination" and "cloud source" refer to an entity that has a network address that can be used as an endpoint for a network connection. The entity may be a physical device (e.g., a server) or a virtual entity (e.g., a virtual server or virtual storage device). In more general terms, a cloud service provider resource accessible to a customer is a resource owned / managed by a cloud service provider entity that is accessible via a network connection. Often, access is pursuant to an application programming interface or software development kit provided by the cloud service provider.

[0058] The use of the phrase "at least one of" preceding a list with the conjunction "and" should not be treated as an exclusive list and should not be construed as a list of categories with one item from each category unless specifically stated otherwise. The phrase "at least one of A, B, and C" can refer to only one of the listed items, more than one of the listed items, and one or more of the listed items and another unlisted item.

[0059] Illustrative Embodiments

[0060] Exemplary embodiments include the following:

[0061] Embodiment 1: A method comprising: detecting, by a cybersecurity device, a set of one or more packets communicated during a first session; determining whether an application can be identified based at least in part on a set of signatures maintained by the cybersecurity device; forwarding at least a first packet of the set of packets to a cloud-based service based on determining that the application cannot be identified based on the set of signatures maintained by the cybersecurity device; determining by the cloud-based service whether the application can be identified based at least in part on the first packet and a plurality of signatures maintained in a cloud on which the cloud-based service executes, the plurality of signatures including the set of signatures; and, based on the cloud-based service determining that the application can be identified, communicating to the cybersecurity device an indication of the application and a first signature of the plurality of signatures associated with the packets of the application.

[0062]

[0023] Embodiment 2: The method of embodiment 1, further comprising applying a security policy indicative of the application to the set of packets based, at least in part, on the cybersecurity device receiving the indication of the application.

[0063] Embodiment 3: The method of embodiment 1 or 2, further comprising updating the set of signatures with the first signature based on the cybersecurity device obtaining an indication of the first signature from the cloud-based service.

[0064] Embodiment 4: The method of embodiment 3, further comprising identifying the application as associated with the second session based, at least in part, on the cybersecurity device detecting subsequent packets communicated during the second session based on the updated set of signatures maintained by the cybersecurity device.

[0065] Embodiment 5: A method according to any one of embodiments 1 to 4, wherein the set of signatures includes a set of signatures defined for a corresponding set of applications, the plurality of signatures includes a plurality of signatures defined for a corresponding plurality of applications, and the plurality of applications includes the set of applications.

[0066] Embodiment 6: A method according to any one of embodiments 1 to 5, wherein the step of determining whether an application can be identified includes applying the set of signatures to the set of packets to determine whether a match can be identified, and the step of determining whether the application can be identified by the cloud-based service includes applying the plurality of signatures to the first packet to determine whether a match can be identified.

[0067] Embodiment 7: The method of embodiment 6, wherein the first signature is included in the plurality of signatures but not in the set of signatures, and the step of determining that the application can be identified includes determining that the first packet matches the first signature of the plurality of signatures.

[0068] Embodiment 8: The method of any one of embodiments 1 to 7, further including, based on detecting a set of one or more packets communicated during a third session, determining whether an application associated with the third session can be identified based at least in part on the set of signatures maintained by the cybersecurity device; based on determining that an application for the third session cannot be identified, determining whether similar network traffic has previously been determined to be unknown based at least in part on at least one of a source address, a destination address, a port number, and a network communication protocol associated with the set of packets of the third session; and based on determining that similar network traffic has previously been determined to be unknown, determining that the set of packets of the third session is unknown traffic without forwarding any of the set of packets to the cloud-based service.

[0069]

[0023] Embodiment 9: The method of any one of embodiments 1 to 8, further comprising designating the first packet for creation of an application signature based on the cloud-based service determining that the application cannot be identified.

[0070] Embodiment 10: One or more non-transitory machine-readable storage media including program code for classifying network traffic by application class, the program code detecting network traffic of a first session, determining whether the network traffic can be classified into one of a set of application classes, communicating one or more packets of the network traffic to a cloud-based service based on determining that the network traffic cannot be classified into one of the set of application classes, obtaining from the cloud-based service an indication of a first application class and a first signature associated with the communicated one or more packets, associating the indication of the first application class with an identifier of the first session, the first application class not being included in the set of application classes, and updating the set of application classes with the first application class.

[0071] Embodiment 11: The non-transitory machine-readable storage medium of embodiment 10, wherein the program code further determines whether the network traffic can be classified into one of the set of application classes based on a subsequent detection of network traffic of a second session, and determines that the network traffic can be classified into the first application class without communicating the network traffic to the cloud-based service.

[0072] Embodiment 12: A non-transitory machine-readable storage medium as described in embodiment 10 or 11, wherein the program code that determines whether the network traffic can be classified into one of the set of application classes evaluates the network traffic against a set of signatures, each of the set of signatures being associated with a corresponding one of the set of application classes.

[0073] Embodiment 13: The non-transitory machine-readable storage medium of embodiment 12, wherein the program code that determines that the network traffic cannot be classified into one of the set of application classes determines that the network traffic cannot be matched to any of the set of signatures.

[0074] Embodiment 14: A non-transitory machine-readable storage medium as described in any one of embodiments 10 to 13, wherein the program code further classifies the network traffic as unknown traffic based, at least in part, on obtaining an indication from the cloud-based service that the communicated one or more packets could not be classified into an application class.

[0075] Embodiment 15: The non-transitory machine-readable storage medium of any one of embodiments 10 to 14, wherein the program code further determines, based on detection of network traffic of a second session, whether the network traffic can be classified into one of the set of application classes; based on determining that the network traffic of the second session cannot be classified, determines whether previously detected network traffic having at least one of a source address, a destination address, a port number, and a network communication protocol in common with the network traffic was previously classified as unknown traffic; and based on determining that the previously detected network traffic was classified as unknown traffic, classifies the network traffic of the second session as unknown traffic without communicating packets to the cloud-based service.

[0076] Embodiment 16: A non-transitory machine-readable storage medium according to any one of embodiments 10 to 15, wherein the program code further applies a first security policy to the network traffic, the first security policy indicating the first application class.

[0077] Embodiment 17: An apparatus including a processor and a computer-readable storage medium having instructions stored thereon, the instructions, when executed by the processor, causing the apparatus to: obtain a first packet that could not be classified by a cybersecurity device; evaluate the first packet against a plurality of application signatures to classify the first packet, the plurality of application signatures representing a plurality of applications; based on matching the first packet to one of the plurality of application signatures, classify the first packet into an application class of one of the plurality of applications represented by the matching application signature; and communicate the application class into which the first packet was classified and the matching application signature to the cybersecurity device.

[0078] Embodiment 18: The apparatus of embodiment 17, further comprising instructions executable by the processor to cause the apparatus to determine whether the first packet can be classified according to one generic class of a set of generic classes based on determining that the first packet cannot match any of the plurality of application signatures, and to communicate the generic class of the first packet to the cybersecurity device based on determining that the first packet can be classified according to a generic class.

[0079] Embodiment 19: The device of embodiment 17 or 18, further including instructions executable by the processor to cause the device to instruct a new application signature to be created based, at least in part, on the first packet based on determining that the first packet cannot match any of the plurality of application signatures.

[0080] Embodiment 20: The apparatus of embodiment 19, further comprising instructions executable by the processor to cause the apparatus to update the plurality of application signatures with the new application signature based, at least in part, on creation of the new application signature based on the first packet.

[0081] Embodiment 21: A method, comprising: detecting network traffic of a first session; determining whether the network traffic can be classified into one of a set of application classes; communicating one or more packets of the network traffic to a cloud-based service based on determining that the network traffic cannot be classified into one of the set of application classes; associating an indication of the first application class with an identifier of the first session based on obtaining from the cloud-based service an indication of the first application class and a first signature associated with the communicated one or more packets, where the first application class was not included in the set of application classes; and updating the set of application classes with the first application class.

Claims

1. 1. A method comprising: detecting, by the cybersecurity device, a set of one or more packets communicated during the first session; determining whether an application can be identified based at least in part on a set of signatures maintained by the cybersecurity device; Based on the set of signatures maintained by the cybersecurity device, forwarding at least a first packet of the set of packets to a cloud-based service based on determining that the application cannot be identified; determining whether the application can be identified by the cloud-based service based at least in part on the first packet and a plurality of signatures maintained in a cloud in which the cloud-based service executes, the plurality of signatures including the set of signatures; and Based on the cloud-based service determining that the application can be identified, communicating to the cybersecurity device an indication of the application and a first signature of the plurality of signatures associated with packets of the application; and the method further comprises: based on detecting a set of one or more packets communicated during the second session; determining whether an application associated with the second session can be identified based, at least in part, on the set of signatures maintained by the cybersecurity device; Including, determining whether an application can be identified includes applying the set of signatures to the set of packets to determine whether a match can be identified; determining whether the application can be identified by the cloud-based service includes applying the plurality of signatures to the first packet to determine whether a match can be identified; and the first signature is included in the plurality of signatures but not in the set of signatures; and determining that the application can be identified includes determining that the first packet matches the first signature of the plurality of signatures; method.

2. The method further comprises: applying a security policy indicative of the application to the set of packets based, at least in part, on the cybersecurity device receiving the indication of the application; The method of claim 1 , comprising:

3. The method further comprises: updating the set of signatures with the first signature based on the cybersecurity device obtaining an indication of the first signature from the cloud-based service; based on the cybersecurity device detecting subsequent packets communicated during a third session, identifying the application as associated with the third session based, at least in part, on the updated set of signatures maintained by the cybersecurity device; The method of claim 1 , comprising:

4. the set of signatures includes a set of signatures defined for a corresponding set of applications; the plurality of signatures includes a plurality of signatures defined for a corresponding plurality of applications; and the plurality of applications includes the set of applications; The method of claim 1.

5. The method further comprises: based on determining that an application for the second session cannot be identified; determining whether similar network traffic has been previously determined to be unknown based, at least in part, on at least one of a source address, a destination address, a port number, and a network communication protocol associated with the set of packets of the second session; and based on determining that similar network traffic has previously been determined to be unknown; determining that the set of packets of the second session is unknown traffic without forwarding any of the set of packets to the cloud-based service; The method of claim 1 , comprising:

6. 1. An apparatus comprising: a processor; a computer-readable storage medium having instructions stored thereon; The instructions, when executed by the processor, cause the device to: Obtaining a first packet that could not be classified by the cybersecurity device; evaluating the first packet against a plurality of application signatures to classify the first packet; the plurality of application signatures represent a plurality of applications; based on matching the first packet to one of the plurality of application signatures; classifying the first packet into an application class of one of the plurality of applications represented by a matching application signature; communicating to the cybersecurity device the application class into which the first packet was classified and the matching application signature; Let them do so, The device further comprises: based on determining that the first packet cannot match any of the plurality of application signatures; determining whether the first packet can be classified according to one generic class of a set of generic classes; A device that makes it so.

7. The apparatus further comprises: instructions executable by the processor, the device comprising: based on determining that the first packet can be classified according to a generic class; communicating the generic class of the first packet to the cybersecurity device; Make it so, 7. The apparatus of claim 6.

8. The apparatus further comprises: instructions executable by the processor, the device comprising: based on determining that the first packet cannot match any of the plurality of application signatures; directing a new application signature to be created based at least in part on the first packet; and based, at least in part, on creating the new application signature based on the first packet; updating the plurality of application signatures with the new application signature; Make it so, 7. The apparatus of claim 6.

Images