CN117121439A - Increased coverage of application-based traffic classification with local and cloud classification services - Google Patents

Abstract

The cloud-based traffic classification engine maintains a catalog of application-based traffic categories that have been developed based on known applications, and the local traffic classification engine maintains a subset of these categories. 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 a class of traffic, the cloud-based engine forwards the determined class and the corresponding signature to the local engine. The firewall maintains a cache updated with a signature corresponding to the class transmitted by the cloud-based engine. Subsequent network traffic sent from the application may be determined to correspond to the application and classified accordingly locally at the firewall based on the cached signature. As the directory of classification information stored in the cloud expands, localization of the cache to the firewall reduces the latency of traffic classification operations.

Description

Increased coverage of application-based traffic classification with local and cloud classification services

Background

The present disclosure relates generally to the transmission of digital information and to a network architecture or network communication protocol for network security.

As part of enforcing the security policy, the firewall implements traffic classification. Firewalls typically classify network traffic based on ports, network protocols, or a combination thereof. The firewall may also perform deep packet inspection or packet sniffing as part of classifying network traffic. With deep packet inspection, the content of network packets is inspected, which facilitates content-based classification of network traffic based on matching signatures generated from data transmitted via the network packets.

Drawings

Embodiments of the disclosure may be better understood by reference to the drawings.

Fig. 1 depicts a conceptual diagram combining local and cloud-based traffic classification for low-latency classification of network traffic by application.

Fig. 2 depicts a conceptual diagram of automatic collection of unclassified network traffic for application signature creation.

Fig. 3-4 are flowcharts of example operations for classifying detected network traffic by application.

Fig. 5 is a flow diagram of example operations for classifying packets forwarded from a firewall into categories representing applications.

FIG. 6 depicts an example computer system having a local traffic classification engine and a cloud-based traffic classification engine.

Fig. 7 is a flow chart of example operations for classifying detected network traffic by application.

Fig. 8 is a flowchart of example operations for performing cloud-based classification of network traffic by application.

Fig. 9 is a flow chart of example operations for determining applications associated with detected network traffic and classifying the network traffic accordingly.

Detailed Description

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

Overview

The firewall-based traffic classification engine analyzes network traffic based on classification information stored locally on the firewall to classify the network traffic by application. The network traffic may be classified by application based on evaluating the network traffic against the signature representing the application and classifying the network traffic into a class corresponding to the application represented by the matching signature. Although the local traffic classification service provides application-based policy enforcement regardless of whether the detection circumvention technique is in place, the number of signatures that can be stored and utilized locally and the ability to expand with the creation of new signatures is limited due to the hardware limitations of firewalls.

Techniques are disclosed herein for extending coverage of business classification services with a combination of functionality provided by a business classification engine running locally on a firewall and a cloud-based business classification engine running in the cloud. The cloud-based engine maintains a catalog of applications by which network traffic can be classified and corresponding signatures that have been developed, and the local engine maintains a subset of the catalog, which may represent the most commonly used or most frequently accessed applications. Network traffic intercepted by a firewall that cannot be classified by application based on information available locally to the local engine is forwarded to the cloud-based engine for classification based on the larger application catalog in which the network traffic can be classified. Upon classifying traffic into categories representing applications based on signature matching, the cloud-based engine forwards the determined categories indicating the corresponding applications and matching signatures to the local engine. The firewall maintains a cache updated with indications and signatures of corresponding applications transmitted by the cloud-based engine that are not included in the classification information originally installed on the firewall. Subsequent network traffic exchanged during the session involving the application indicated by the class may be classified accordingly by the local engine based on the cached signature. By caching the signature determined based on the network traffic it intercepts, the cache is localized to the firewall, reducing the delay of local traffic classification operations, even if the directory of classification information stored in the cloud is enlarged. Further, extending traffic classification to a cloud maintaining a catalog of classification information increases the scope of applications from which network traffic can be classified, thereby reducing the amount of network traffic delivered as unknown traffic and improving application-based security policy enforcement at firewalls.

Network traffic of applications whose signature has not been determined and thus cannot be classified by the local engine or cloud-based engine may be forwarded by the cloud-based engine to the signature creation service. Because creation of application signatures is traditionally accomplished through manual effort to set up application environments and capture network traffic, eliminating this step by automatically forwarding detected network traffic directly to the signature creation service reduces the cost and associated challenges of manual research and development to create new signatures.

Example illustrations

FIG. 1 depicts a conceptual diagram combining local and cloud-based traffic classification for low-latency classification of network traffic by application. Firewall 129 monitors and controls network traffic for clients 101 that is transmitted in and out through network 127. A local traffic classification engine ("local engine") 103 executing as part of the firewall 129 classifies detected network traffic by corresponding application. A cloud-based traffic classification engine ("cloud-based engine") 107 runs in the 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 application class cache ("cache") 105, which stores traffic classification information communicated from cloud-based engine 107 to local engine 103.

FIG. 1 is labeled with a series of letters A-F, which represent various stages of operation. Although these stages are ordered for this example, these stages illustrate one example to aid in understanding the present disclosure and should not be used to limit the claims. The subject matter that falls within the scope of the claims may vary depending on the order and some operations.

In stage a, firewall 129 detects a session initiated by client 101 with server 109, and server 109 maintains the resources of the application named "eMarket". The application "eMarket" may be a web (network) application running on the server 109, and the client 101 requests access to the application. Firewall 129 detects packets 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 packets 121 and/or requests issued by client 101 to classify network traffic by application so that security policies specifying appropriate applications can be applied.

In stage B, the local engine 103 evaluates the packet 121 and determines whether the packet 121 can be classified into an application class. The local engine 103 maintains application categories 123, the application categories 123 comprising categories representing the network traffic of the application. Each class of network traffic defined in the application class 123 representing an application is also associated with a signature of the packet of the application. The signatures included in the application class 123 may include application signatures and/or context-based signatures applied as part of packet decoding. The local engine 103 determines whether the packet 121 can be classified into one of the application categories 123 based on evaluating the signatures of the application categories 123 against the packet 121 to determine whether one of the signatures matches the packet 121. The local engine 103 may also read the signature corresponding to the application class from the cache 105 and evaluate the signature read for the packet 121 to determine if the cached signature matches the packet 121 and the packet 121 may thus be classified into the corresponding application class. In this example, local engine 103 determines that packet 121 cannot be classified into one of the categories maintained locally in application category 123 and cache 105; that is, neither the application class 123 nor the cache 105 includes an application class and associated signature that represent an application named "eMarket".

In stage C, local engine 103 forwards at least packet 121A of packets 121 to cloud-based engine 107 for classification. The local engine 103 may forward all, a subset, or one of the packets 121 to the cloud-based engine 107 as specified by the packet forwarding policy 125. Packet forwarding policy 125 may also indicate that local engine 103 should forward to a portion of the payload of cloud-based engine 107 (e.g., based on offset value(s), certain fields of the packet, etc.). Packets that are unclassified by the local engine 103 are initially forwarded to the cloud-based engine 107 for further evaluation based on an application category directory ("directory") 115. The catalog 115 includes a broad set of defined application categories and corresponding application signatures, context-based signatures, and the like. The application categories 123 accessed locally by the local engine 103 comprise a subset of the application categories stored in the directory 115, so forwarding packets that are not classified into one of the application categories 123 to the cloud-based engine 107 expands the scope of applications to which the packets can be classified.

At stage D, cloud-based engine 107 evaluates packet 121A and determines whether packet 121A can be classified into one of the application categories included in catalog 115. For example, cloud-based engine 107 may evaluate packet 121A against signatures associated with application categories stored in a catalog to determine whether a match may be identified. In this example, the signature representing the application "eMarket" is not included in the application category 123, but is included in the catalog 115. The cloud-based engine 107 thus determines that the packet 121A can be classified into an application category corresponding to the application "eMarket" based on the signature the application includes in the catalog 115 and determining that the signature 119 representing the application "eMarket" matches the packet 121A.

In stage E, the cloud-based engine 107 transmits an indication of the application class representing the application "eMarket" and the corresponding signature 119 to the local engine 103. The local engine 103 obtains the signature 119 corresponding to the application "eMarket" and an indication of the application class from the cloud-based engine 107 and classifies the packet 121 into the application class of "eMarket". As part of classifying packet 121, local engine 103 can associate a session ID of the session between client 101 and server 109 with an indication of the application class to which packet 121 is classified, such that packet 121 and any subsequent packets transmitted during the session are associated with an application class representing application "eMarket". Classifying the packets 121 as application-based traffic classes allows the firewall 129 to subsequently apply fine-grained policies defined specifically for the application class corresponding to application "eMarket".

In stage F, the local engine 103 updates the cache 105 with the indication of the application class and signature 119 transmitted from the cloud-based engine. The local engine 103 writes the signature 119 and the corresponding application class defined for the application "eMarket" to the cache 105. Upon detecting a packet sent as part of a subsequent session between the client 101 and the server 109 for accessing the content of the application "eMarket", the local engine 103 will be able to classify the packet locally into the appropriate application class based on reading the signature 119 from the cache 105 and evaluating the packet exchanged during the session against the signature 119, rather than sending the packet to the cloud-based engine 107 for classification.

Fig. 2 depicts a conceptual diagram of automatic collection of unclassified network traffic for application signature creation. While collecting network traffic for applications for application signature creation is traditionally a laborious manual task, the local engine 103 and cloud-based engine 107 may be used to automatically collect the network traffic. Fig. 2 depicts an example in which the local engine 103 and the cloud-based engine 107 determine whether a packet 221 of a session between the client 101 and the server 209 storing a resource of an application named "vstream" can be classified into an application class.

The local engine 103 sends at least packet 221A of the packets 221 specified by the packet forwarding policy 125 to the cloud-based engine 107. The local engine 103 determines that the packet 221 cannot be classified into one of the application categories 123 or for reading the signature from the cache 105, as similarly described with reference to fig. 1. Cloud-based engine 107 then determines that packet 221A cannot be classified into one of the application categories included in directory 115. For example, a signature representing application "vstream" may not have been created and inserted into directory 115. Cloud-based engine 107 communicates to local engine 103 that packet 221 should be classified as unknown traffic and applies the policies of firewall 129 accordingly.

Based on determining that packet 221A cannot be classified into an application category in directory 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 execute on servers outside of cloud 217 and firewall 219. The cloud-based engine 107 may send additional ones of the packets 221 (e.g., in addition to the packet 221A) to the signature creation service 211 for storage in the repository 213 of collected packets. The cloud-based engine 107 may include additional identifying information of the packet 221, such as a source address, destination address, port number, and/or network protocol, in communication with the signature creation service 211 so that similar packets classified into the same application class may be grouped for signature creation. Forwarding the packet 221 to the signature creation service 211 allows subsequent creation of a signature for an application named "vstream". Later, once an application signature representing application "vstream" has been created, a signature and indication of the application category corresponding to "vstream" may be inserted into directory 115 and/or application category 123. As a result, the local engine 103 and the cloud-based engine 107 can classify the detected into an application category representing "vstream" later.

Fig. 3-5 are flowcharts of example operations for increased coverage of application-based traffic classification by utilizing local and cloud-based traffic classification engines. To keep pace with the previous figures, 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"). The names chosen for the program code are not limiting to the claims. The structure and organization of programs may vary depending on the platform, programmer/architect preference, programming language, etc. Furthermore, the names of the code units (programs, modules, methods, functions, etc.) may vary for the same reasons, and may be arbitrary.

Fig. 3-4 are flowcharts of example operations for classifying detected network traffic by application. The example operations in fig. 3 are performed by a local engine, which may be performed as part of a firewall. At block 301, the local engine detects network traffic of a session. The network traffic may be a request to access an application issued from a client that initiates a session to a server, data sent from the server to the client in response, a combination thereof, and the like.

At block 302, the local engine applies an available signature set from a catalog representing signatures of applications to network traffic. Applying the signature set to network traffic refers to evaluating the signatures against the network traffic to determine if a matching signature can be found. The signature catalog includes indications of a plurality of applications by which network traffic may be classified and a plurality of signatures, such as application signatures and/or protocol-based signatures, that represent corresponding ones of the plurality of applications. Each signature representing an application may be indicated as a criterion for classifying network traffic into a category corresponding to the application. The set of signatures available to the local engine is a subset of the catalog of signatures that can be accessed locally and may be the signatures representing the most popular or most commonly accessed applications. The signature set applied to the network traffic may also include signatures read from a signature cache maintained for the firewall. The local engine may apply the signature set or a different subset thereof at one or more stages of classifying network traffic. For example, the local engine may apply an application signature to the network traffic in a first phase, and may then apply an additional signature corresponding to a communication protocol associated with the network traffic (e.g., a signature for hypertext transfer protocol (HTTP) traffic, file Transfer Protocol (FTP) traffic, etc.) as part of traffic decoding in a second phase.

At block 303, the local engine determines whether a matching signature is found as a result of applying the signature set to the network traffic. The local engine determines whether the network traffic matches a first one of the signatures. Identifying the matching signature facilitates classifying network traffic into categories corresponding to applications having the matching signature. If a match is found, operation continues at block 304. If no match is found, operation continues at block 305.

At block 304, the local engine classifies the network traffic of the session into application-based categories corresponding to matching signatures. The application-based category 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 of the session with an indication of a class to which the network traffic is classified such that subsequent packets detected during the session are also associated with the determined class. The security policies defined specifically for the application may be applied to network traffic and any network traffic that is subsequently detected during the session. Operation continues at transition point a, which continues at transition point a of fig. 4.

At block 305, the local engine determines whether similar network traffic has been 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 to reduce repeated uploading of unknown network traffic with the same characteristics to the cloud and thus reduce cost. 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 metadata of the network traffic (e.g., based on header(s) of the network traffic) against an 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 is classified as unknown traffic. If no similar network traffic has been classified as unknown, operation continues at block 306. If similar network traffic has been classified as unknown, operation continues at transition point B, which continues at transition point B of fig. 4.

At block 306, the local engine forwards one or more packets of network traffic to the cloud-based service for classification. Policies attached to (e.g., installed on or otherwise accessible to) the local engine may specify a portion of network traffic that should be forwarded/uploaded to the cloud-based service. For example, a policy may specify whether one or each detected packet that makes up network traffic should be forwarded to a cloud-based service. Policies may also represent a portion of packets that should be forwarded to the cloud. As one example, a policy may indicate whether the entire payload should be forwarded or some portion of the payload. Operations performed by the cloud-based service based on receiving network traffic forwarded from the local engine are described with reference to fig. 5. Operation continues at transition point C, which continues at transition point C of fig. 4.

At block 407, the local engine determines whether the network traffic can be classified by 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 of how to classify the forwarded packet(s). If the forwarded packet(s) can be classified by application, the local engine can obtain an indication of the class of the application and a corresponding signature to which the forwarded packet(s) match. If the forwarded packet(s) cannot be classified by application, the local engine may obtain an indication from the cloud-based service that the forwarded packet(s) may be classified as unknown traffic. If the network traffic can be classified into a traffic class representing an application, operation continues at block 409. If the network traffic cannot be classified into a traffic class representing an application, operation continues at block 413.

At block 409, the local engine updates the signature set with the signature transmitted from the cloud-based service and an indication of the category. For example, the local engine may write the signature transmitted from the cloud-based service and the indication of the corresponding application at block 407 to a signature cache so that the signature may be locally accessed for subsequent traffic classification events. The signature written to the cache may be a content-based signature and/or a context-based signature representing the application. The indication of a category may be a name, identifier (ID), etc. of the category, which may correspond to the name, ID, etc. of the application it represents. Later in subsequent detection of network traffic during different sessions involving the application, the local engine may read the signature from the cache and classify the network traffic accordingly at block 303 instead of forwarding the network traffic to the cloud-based service for classification.

At block 411, the local engine associates an indication of the category with the session. For example, the local engine may associate the name, ID, etc. of the category with the session ID of the session maintained by the local engine. Associating the indication of the traffic class with the session effectively classifies network traffic transmitted as part of the session having the session ID into the class. The security policies specifically defined for the application based on the specified class may then be applied to the network traffic of the session.

At block 413, the local engine classifies the network traffic into a category of unknown traffic. The local engine may associate names, IDs, etc. for unknown traffic categories with a session (e.g., with the session ID of the session) such that any network traffic exchanged during the session may be handled as unknown traffic and apply the corresponding security policies defined for the unknown traffic.

At block 415, the local engine updates the maintained indication of unknown traffic with metadata for the network traffic. The local engine may add a new entry in the indication of unknown traffic (e.g., write a new entry in the cache) indicating a source address, destination address, port number, and/or network protocol associated with the network traffic, which may be determined based on the header(s) of the network traffic and based on decoding the network traffic. At block 305, subsequently detected network traffic associated with similar combinations of these metadata may be identified as potentially unknown.

Fig. 5 is a flow diagram of example operations for classifying packets forwarded from a firewall into categories representing applications. The example operations in fig. 5 are performed by a cloud-based engine running in the cloud. Example operations assume that one or more unclassified packets have been forwarded from a local engine executing on a firewall, as described with reference to fig. 3.

At block 501, a cloud-based engine obtains one or more packets detected by and forwarded from a firewall. Each obtained packet may include a header and a payload or a specified portion of the payload. The portion of the packet (e.g., a portion of the payload) to be forwarded to the cloud-based engine may be defined by policies stored on the firewall.

At block 503, the cloud-based engine applies a signature from the signature catalog to the packet to determine whether the packet can be classified into a category representing the application. The cloud-based engine may maintain an indication of a plurality of categories corresponding to the application and one or more corresponding criteria for classifying the packet into each category. One or more criteria for classifying a packet into a class indicates signature(s) from a signature catalog that represents the same application as the class such that if the signature indicated in the one or more criteria matches the packet, the packet is classified into the class. The signature catalog includes each of the signatures, such as an application signature applied to decoders of known network protocols and a context-based signature, which is predefined based on network traffic sent to/from the application. The signature catalog stored in the cloud can be distinguished from the signature stored on the firewall for which the packet was originally evaluated in that the signature stored on the firewall is a subset of the signature catalog. If the signature is known or has been defined for an application associated with the session during which the packet was detected, the signature of the application signature catalog should result in a match so that the packet can be classified into the corresponding class.

At block 505, the cloud-based engine determines whether the packet can be classified into one of the categories based on signature matching. If one of the signatures of the signature catalog matches a packet, the packet may be classified into a category. If the packet can be classified into a traffic class, operation continues at block 507. If the packet cannot be classified into the traffic class, operation continues at block 509.

At block 507, the cloud-based engine communicates an indication of the class of the packet and the matching signature to the firewall. The class of the packet is the class corresponding to the signature that the packet matches. The indication of a category may be the name, ID, etc. of the category or the application it represents. The signature transmitted to the firewall is a packet-matched signature.

At block 509, the cloud-based engine determines whether the packet can be classified into a generic traffic class. The generic traffic class represents a class of applications that have common characteristics, such as "web browsing" of browser-based applications or "unknown_tcp" of applications that use unknown Transmission Control Protocol (TCP) ports. The cloud-based engine may 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, wherein the criteria may indicate one or more characteristics that the packet header and/or payload should exhibit in order 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 met. If the packet can be classified into a generic traffic class, then operation continues at block 511. If the packet cannot be classified into the generic traffic class, operation continues at block 513.

At 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. While the generic class does not have a corresponding signature defined for the known application, the generic class into which the packet is classified allows the firewall to implement security policies defined at the level of the generic class of the application, rather than at the level of the port number and/or network protocol.

At block 513, the cloud-based engine designates a packet for signature creation. Designating packets for signature creation may include sending the packets to an external server, for example, where packets that cannot be classified are stored. The cloud-based engine may also associate port numbers, source addresses, destination addresses, and/or network protocols extracted from packet headers or traffic decoding, by which packets may be distinguished, with the packets so that similar traffic may be aggregated to create common signatures and traffic categories.

At block 515, the cloud-based engine communicates to the firewall that the packet cannot be classified by application. The communication to the firewall may indicate that the packet cannot be classified into any class corresponding to the application, or the packet may be classified as unknown traffic. Thus, packets detected during a session may be considered unknown traffic for the purpose of applying firewall policies.

Variants

The flowcharts are provided to aid in understanding the illustrations and are not intended to limit the scope of the claims. The flow diagrams depict 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 the operations may be performed in a different order. For example, the operations depicted in blocks 413 and 415 may be performed in parallel or concurrently. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by program code. The program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable machine or apparatus.

As will be appreciated, aspects of the present disclosure may be embodied as systems, methods, or program code/instructions stored in one or more machine-readable media. Thus, aspects may take the form of hardware, software (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects, all generally referred to herein as a "circuit," module, "or" system. The functionality presented as separate modules/units in the example illustrations may be organized differently according to any of platform (operating system and/or hardware), application ecosystem, interface, programmer preference, programming language, administrator preference, etc.

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 that employs any one or combination of electronic, magnetic, optical, electromagnetic, infrared, or semiconductor techniques to store program code. More specific examples (a non-exhaustive list) of the machine-readable storage medium would include the following: portable computer diskette, hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine-readable storage medium may be any tangible medium that can contain, or 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.

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, electro-magnetic, optical, or any suitable combination thereof. A machine-readable signal medium may be any machine-readable medium that is not a machine-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a machine-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code/instructions may also be stored in a machine-readable medium that can direct a machine to function in a particular manner, such that the instructions stored in the machine-readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

FIG. 6 depicts an example computer system having a local traffic classification engine and a cloud-based traffic classification engine. The computer system includes a processor 601 (which may include multiple processors, multiple cores, multiple nodes, and/or implement 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 machine-readable media already 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 the network traffic based on an associated application and forwards unknown network traffic to the cloud-based traffic classification engine 613 for identification, the cloud-based traffic classification engine 613 identifies the network traffic by utilizing a broader catalog of network traffic classes than are available to the local traffic classification engine 611, for example, the local traffic classification engine 611 may be implemented on a firewall and the cloud-based traffic classification engine 613 may be implemented in the cloud, any of the foregoing functions may be implemented in part (or in whole) on hardware and/or the processor 601, for example, the functions may be implemented with application specific integrated circuits, logic implemented in the processor 601, coprocessors on peripheral devices or cards, etc., further implementations may include fewer or additional components not shown in fig. 6 (e.g., video cards, sound cards, additional network interfaces, peripheral devices, etc., the processor 601 and network interface 605 are coupled to the bus 603, although shown as coupled to the bus 603, memory 607 may be coupled to processor 601.

While the foregoing is a full description of the exemplary embodiments, the language is somewhat limited when describing the innovations. Furthermore, there are different requirements of regional and national Intellectual Property (IP) authorities. In view of the constraints of languages and the requirements of countless national/regional IP authorities, the following description and corresponding flowcharts attempt to disclose the technology in slightly different languages. The phrase "executing program code" refers to program code executing with any of a myriad of executing implementations (such as computers, security devices, virtual machines, cloud-based services, etc.).

Fig. 7 is a flow chart of example operations for classifying detected network traffic by application. At block 701, program code executing a network security device (e.g., a firewall) detects a set of one or more packets transmitted during a first session. At block 703, program code executing the network security device determines whether the application can be identified based at least in part on a signature set maintained by the network security device. In block 705, in accordance with a determination that an application cannot be identified based on a signature set maintained by a network security device, program code executing the network security device forwards at least a first packet of a set of packets to a cloud-based service. At block 707, program code executing 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 is running, wherein the plurality of signatures includes a signature set. At block 709, based on determining that the application may be identified, program code executing the cloud-based service transmits an indication of the application and a first signature of a plurality of signatures associated with the packet of the application to the network security device. At block 711, program code executing the network security device receives an indication of an application and a first signature.

FIG. 8 is a flowchart of example operations for performing cloud-based classification of network traffic by application. At block 801, program code is executed to detect network traffic for a first session. At block 803, the execution program code determines whether the network traffic can be classified into one of the application categories in the application category set. At block 805, based on a determination that network traffic cannot be classified into one of the application categories in the application category set, program code is executed to communicate one or more packets of network traffic to the cloud-based service. At block 807, based on obtaining an indication of a first application class associated with the transmitted one or more packets from the cloud-based service and the first signature, the execution program code associates the indication of the first application class with an identifier of the first session, wherein the first application class is not included in the set of application classes. At block 809, the execution program code updates the set of application classes with the first application class.

Fig. 9 is a flow chart of example operations for determining applications associated with detected network traffic and classifying the network traffic accordingly. At block 901, the program code is executed to obtain a first packet that cannot be classified by the network security device. At block 903, the execution program code evaluates the first packet against a plurality of application signatures to classify the first packet, wherein 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, the execution 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 execution program code communicates the classified application class of the first packet and the matching application signature to the network security device.

While various aspects of the present disclosure have been described with reference to various embodiments and uses, it should be understood that these aspects are illustrative and that the scope of the claims is not limited to these aspects. In general, techniques for increased coverage by application-based traffic classification and policy enforcement that extend the scope of traffic classification services as described herein may be implemented with facilities consistent with any one or more hardware systems. Many variations, modifications, additions, and improvements are possible.

Multiple instances may be provided for 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 illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of this disclosure. Generally, structures and functions presented as separate components in an example configuration may be implemented as a combined structure or component. Similarly, structures and functions presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure.

Terminology

For efficiency and ease of explanation, this description uses shorthand terminology relating to cloud technology. When referring to "cloud," this description refers to resources of a cloud service provider. For example, the cloud may contain servers, virtual machines, and storage devices of a cloud service provider. The terms "cloud destination" and "cloud source" refer to entities having network addresses that can be used as endpoints of a network connection. The entity may be a physical device (e.g., a server) or may be a virtual entity (e.g., a virtual server or virtual storage device). More generally, a customer-accessible cloud service provider resource is a resource owned/managed by a cloud service provider entity that is accessible over a network connection. Typically, access is made in accordance with an application programming interface or software development kit provided by a cloud service provider.

Unless specifically stated otherwise, the use of the phrase "at least one" prior to a list with the conjunctions "and" should not be considered an exclusive list and should not be construed as having a list of categories with one item from each category. The term enumerating "at least one of A, B and C" may be violated by only one listed item, multiple listed items, one or more items in the list, and another unlisted item.

Example embodiment

Example embodiments include the following:

example 1: a method, comprising: detecting, by the network security device, a set of one or more packets transmitted during the first session; determining whether an application can be identified based at least in part on a signature set maintained by the network security device; in accordance with a determination that the application cannot be identified based on the signature set maintained by the network security device, forwarding at least a first packet of a set of packets to a cloud-based service; determining, by the cloud-based service, whether the application can be identified based at least in part on the first group and a plurality of signatures maintained in a cloud in which the cloud-based service is running, wherein the plurality of signatures includes the signature set; and determining, based on the cloud-based service, that the application can be identified, transmitting, to the network security device, an indication of the application associated with the packet of the application and a first signature of the plurality of signatures.

Example 2: the method of embodiment 1, further comprising applying a security policy indicating an application to the set of packets based at least in part on the network security device receiving the indication of the application.

Example 3: the method of embodiment 1 or 2, further comprising updating the signature set with the first signature based on an indication that the network security device obtained the first signature from the cloud-based service.

Example 4: the method of embodiment 3, further comprising identifying the application as being associated with the second session based at least in part on an updated signature set maintained by the network security device based on the network security device detecting a subsequent packet transmitted during the second session.

Example 5: the method of any of embodiments 1-4, wherein the signature set comprises a signature set defined for a corresponding application set, wherein the plurality of signatures comprises a plurality of signatures defined for a corresponding plurality of applications, and wherein the plurality of applications comprises the application set.

Example 6: the method of any of embodiments 1-5, wherein determining whether an application can be identified comprises applying the set of signatures to the set of packets to determine whether a match can be identified, and wherein determining, by the cloud-based service, whether the application can be identified comprises applying the plurality of signatures to the first packet to determine whether a match can be identified.

Example 7: the method of embodiment 6, wherein the first signature is included in the plurality of signatures but not in the signature set, and wherein determining that the application can be identified comprises determining that the first packet matches a first signature of the plurality of signatures.

Example 8: the method of any of embodiments 1-7, further comprising determining, based on detecting a set of one or more packets transmitted during the third session, whether an application associated with the third session can be identified based at least in part on a signature set maintained by the network security device; based on determining that the application for the third session cannot be identified, determining whether similar network traffic was 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 a set of packets of the third session; and based on determining that similar network traffic was previously 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.

Example 9: the method of any of embodiments 1-8, further comprising determining from the cloud-based service that the application cannot be identified, designating a first group for creating an application signature.

Example 10: one or more non-transitory machine-readable media comprising program code for classifying network traffic by application class, the program code to: detecting network traffic of a first session; determining whether the network traffic can be classified into one of a set of application classes; transmitting one or more packets of the network traffic to a cloud-based service based on a determination that the network traffic cannot be classified into one of the set of application categories; associating an indication of a first application class with an identifier of the first session based on obtaining an indication of the first application class and a first signature associated with the transmitted one or more packets from the cloud-based service, wherein the first application class is not included in the set of application classes; and updating the set of application categories with the first application category.

Example 11: the non-transitory machine-readable medium of embodiment 10, further comprising program code to: determining whether the network traffic can be classified into one of the application categories based on a subsequent detection of the network traffic of the second session; and determining that the network traffic can be classified into the first application class without communicating the network traffic to the cloud-based service.

Example 12: the non-transitory machine-readable medium of embodiment 10 or 11, wherein the program code for determining whether network traffic can be classified into one of the application categories comprises program code for evaluating network traffic against a set of signatures, wherein each signature of the set of signatures is associated with a corresponding one of the application categories.

Example 13: the non-transitory machine-readable medium of embodiment 12, wherein the program code to determine that network traffic cannot be classified into one of the set of application categories comprises program code to determine that network traffic cannot match any of the set of signatures.

Example 14: the non-transitory machine-readable medium of any of embodiments 10-13, further comprising program code to classify network traffic as unknown traffic based at least in part on obtaining an indication from the cloud-based service that the transmitted one or more packets cannot be classified into the application class.

Example 15: the non-transitory machine-readable medium of any of embodiments 10-14, further comprising program code to: determining whether the network traffic can be classified into one of the application categories based on the detection of the network traffic of the second session; determining 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 is previously classified as unknown traffic based on the determination that the network traffic of the second session cannot be classified; and classifying the network traffic of the second session as unknown traffic based on a determination that the previously detected network traffic is classified as unknown traffic without transmitting packets to the cloud-based service.

Example 16: the non-transitory machine-readable medium of any of embodiments 10-15, further comprising program code to apply a first security policy indicating a first application class to network traffic.

Example 17: an apparatus, comprising: a processor; and a computer readable medium having instructions stored thereon, the instructions being executable by the processor to cause the apparatus to: obtaining a first packet that cannot be classified by the network security device; evaluating the first packet against a plurality of application signatures to classify the first packet, wherein the plurality of application signatures represent a plurality of applications; classifying the first packet into an application class of one of the plurality of applications represented by a matching application signature based on a match of the first packet with the one of the plurality of application signatures; and transmitting to the network security device the application class classifying the first packet and the matching application signature.

Example 18: the apparatus of embodiment 17, further comprising instructions executable by the processor to cause the apparatus to: determining whether the first packet is capable of classification according to a generic class of a generic class set based on a determination that the first packet cannot match any of the plurality of application signatures; and transmitting the generic class of the first packet to the network security device based on the determination that the first packet can be classified according to the generic class.

Example 19: the apparatus of embodiment 17 or 18, further comprising instructions executable by the processor to cause the apparatus to indicate that a new application signature is to be created based at least in part on the first packet based on a determination that the first packet cannot match any of the plurality of application signatures.

Example 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 creating the new application signature based on the first packet.

Example 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 categories; transmitting 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 categories; associating an indication of a first application class with an identifier of the first session based on obtaining an indication of the first application class and a first signature associated with the transmitted one or more packets from the cloud-based service, wherein the first application class is not included in the set of application classes; and updating the set of application categories with the first application category.

Claims (15)

1. A method, comprising:

detecting, by the network security device, a set of one or more packets transmitted during the first session;

determining whether an application can be identified based at least in part on a signature set maintained by the network security device;

in accordance with a determination that the application cannot be identified based on the signature set maintained by the network security device, forwarding at least a first packet of a set of packets to a cloud-based service;

determining, by the cloud-based service, whether the application can be identified based at least in part on the first group and a plurality of signatures maintained in a cloud in which the cloud-based service is running, wherein the plurality of signatures includes the signature set; and

determining, based on the cloud-based service, that the application can be identified, transmitting, to the network security device, an indication of the application associated with the packet of the application and a first signature of the plurality of signatures.

2. The method of claim 1, further comprising applying a security policy indicating an application to the set of packets based at least in part on the network security device receiving the indication of the application.

3. The method of claim 1, further comprising,

Based on an indication that the network security device obtained the first signature from the cloud-based service, the signature set is updated with the first signature, and, optionally,

the application is identified as being associated with the second session based at least in part on an updated signature set maintained by the network security device based on the network security device detecting subsequent packets transmitted during the second session.

4. The method of claim 1, wherein the signature set comprises a signature set defined for a corresponding application set, wherein the plurality of signatures comprises a plurality of signatures defined for a corresponding plurality of applications, and wherein the plurality of applications comprises the application set.

5. The method according to claim 1,

wherein determining whether an application can be identified comprises applying the signature set to the set of packets to determine whether a match can be identified;

wherein determining, by the cloud-based service, whether the application can be identified includes applying the plurality of signatures to the first packet to determine whether a match can be identified, and, optionally,

wherein the first signature is included in the plurality of signatures but not in the signature set, and wherein determining that the application can be identified comprises determining that the first packet matches a first signature of the plurality of signatures.

6. The method of claim 1, further comprising,

based on detecting a set of one or more packets transmitted during the third session, determining whether an application associated with the third session can be identified based at least in part on a set of signatures maintained by the network security device;

based on determining that the application for the third session cannot be identified, determining whether similar network traffic was 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 a set of packets of the third session; and

based on determining that similar network traffic was previously determined to be unknown, it is determined that the set of packets for the third session is unknown traffic without forwarding any of the set of packets to the cloud-based service.

7. One or more non-transitory machine-readable media comprising program code for classifying network traffic by application class, the program code to:

detecting network traffic of a first session;

determining whether the network traffic can be classified into one of a set of application classes;

transmitting one or more packets of the network traffic to a cloud-based service based on a determination that the network traffic cannot be classified into one of the set of application categories;

Associating an indication of a first application class with an identifier of the first session based on obtaining an indication of the first application class and a first signature associated with the transmitted one or more packets from the cloud-based service, wherein the first application class is not included in the set of application classes; and

the set of application categories is updated with the first application category.

8. The non-transitory machine readable medium of claim 7, further comprising program code to,

determining whether the network traffic can be classified into one of the application categories based on a subsequent detection of the network traffic of the second session; and

it is determined that the network traffic can be classified into the first application class without communicating the network traffic to the cloud-based service.

9. The non-transitory machine-readable medium of claim 7,

wherein the program code for determining whether network traffic can be classified into one of the application categories comprises program code for evaluating network traffic against a set of signatures, wherein each signature of the set of signatures is associated with a corresponding one of the application categories,

Wherein the program code for determining that network traffic cannot be classified into one of the set of application categories comprises program code for determining that network traffic cannot match any of the set of signatures.

10. The non-transitory machine-readable medium of claim 7, further comprising program code to classify network traffic as unknown traffic based at least in part on obtaining an indication from the cloud-based service that the transmitted one or more packets cannot be classified into an application class.

11. The non-transitory machine readable medium of claim 7, further comprising program code to,

determining whether the network traffic can be classified into one of the application categories based on the detection of the network traffic of the second session;

determining 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 is previously classified as unknown traffic based on a determination that the network traffic of the second session cannot be classified; and

based on a determination that previously detected network traffic is classified as unknown traffic, network traffic of the second session is classified as unknown traffic without transmitting packets to the cloud-based service.

12. The non-transitory machine-readable medium of claim 7, further comprising program code to apply a first security policy indicating a first application class to network traffic.

13. An apparatus, comprising:

a processor; and

a computer-readable medium having instructions stored thereon, the instructions being executable by a processor to cause the device to:

obtaining a first packet that cannot be classified by the network security device;

evaluating the first packet against a plurality of application signatures to classify the first packet, wherein the plurality of application signatures represent a plurality of applications;

classifying the first packet into an application class of one of the plurality of applications represented by a matching application signature based on a match of the first packet with the one of the plurality of application signatures; and

the application class classifying the first packet and the matching application signature are transmitted to the network security device.

14. The apparatus of claim 13, further comprising instructions executable by the processor to cause the apparatus to:

determining whether the first packet is capable of classification according to a generic class of a generic class set based on a determination that the first packet cannot match any of the plurality of application signatures; and

The generic class of the first packet is transmitted to the network security device based on a determination that the first packet can be classified according to the generic class.

15. The apparatus of claim 13, further comprising instructions executable by the processor to cause the apparatus to:

indicating that a new application signature is to be created based at least in part on the first packet based on a determination that the first packet cannot match any of the plurality of application signatures, and, optionally

A plurality of application signatures are updated with the new application signature based at least in part on the first packet creating the new application signature.