Patent Description:
A virtual private cloud (VPC) is an on-demand configurable pool of shared computing resources allocated within a public cloud environment. The VPC provides isolation for a user from other cloud users. The VPC may execute one or more virtual machines (VMs) which may communication with the user's on-premises network or other remote resources via a virtual private network (VPN). Due to the potential scale and complexity of the VPC, which may include any number of VMs, network gateways, load balancers, etc., significant network configuration is often necessary to operate and maintain the VPC. For example, it is often necessary to optimize firewall configurations by updating firewall rules. The complex nature of firewall rules means makes it difficult for users to understand what rules are in use and what the effect of these rules are. One of the problems this creates is that it is difficult to maintain firewall rules over time. Rules which once made sense may not be useful as operating environments change.

<CIT> discloses a process for predicting a ranking value of an unimplemented firewall rule based on match counts and/or ranking values of implemented firewall rules.

One aspect of the disclosure provides a computer-implemented method, that, when executed on data processing hardware causes the data processing hardware to perform operations for training a firewall utilization model. The operations include receiving firewall utilization data for connection requests received by a firewall during a utilization period, the firewall utilization data including hit counts during the utilization period for each sub-rule of a set of sub-rules associated with at least one firewall rule. The operations also include generating training data based on the firewall utilization data, the training data including unused sub-rules corresponding to sub-rules having no hits during the utilization period and hit sub-rules corresponding to sub-rules having more than zero hits during the utilization period. The operations also include training a firewall utilization model on the training data. The operations further include for each sub-rule of the set of sub-rules associated with the at least one firewall rule, determining, using the trained firewall utilization model, a corresponding sub-rule utilization probability indicating a likelihood the sub-rule will be used for a future connection request.

The operations further include determining firewall attribute groupings for the at least one firewall rule, each of firewall attribute groupings including at least one firewall attribute, and determining a first set of the sub-rules associated with the at least one firewall rule based on the firewall attribute groupings.

The operations further include receiving a plurality of firewall logs associated with connection requests received by the firewall during the utilization period. The operations include filtering the plurality of the firewall logs based on a filter criteria. The operations include determining a second set of sub-rules associated with the plurality of firewall logs, and generating the utilization data based on the first set of sub-rules and the second set of sub-rules. In some implementations, the firewall attribute groupings include at least three of a source attribute grouping, a target attribute grouping, a port range, or an internet protocol (IP). In some examples, the source attribute grouping includes source IP ranges, source tags, and source service accounts. In some configurations, the target attribute grouping includes target tags and target service accounts.

In some configurations, the operations further include receiving firewall reachability insights from a reachability module, generating firewall utilization insights based on the corresponding sub-rule utilization probability determined for each sub-rule, aggregating the firewall reachability insights and the firewall utilization insights, and generating firewall configuration recommendations based on the aggregated firewall reachability insights and firewall utilization insights. In some examples, the operations include determining unused firewall rule attributes during the utilization period, for every unused firewall rule attribute, aggregating the sub-rule utilization probabilities for all sub-rules including the unused firewall rule attribute, and determining a probability that a firewall attribute will be hit in the future based on aggregated sub-rule probabilities.

Another aspect of the disclosure provides system for training a firewall utilization model. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed by the data processing hardware, cause the data processing hardware to perform operations. The operations include receiving firewall utilization data for connection requests received by a firewall during a utilization period, the firewall utilization data including hit counts during the utilization period for each sub-rule of a set of sub-rules associated with at least one firewall rule. The operations also include generating training data based on the firewall utilization data, the training data including unused sub-rules corresponding to sub-rules having no hits during the utilization period and hit sub-rules corresponding to sub-rules having more than zero hits during the utilization period. The operations also include training a firewall utilization model on the training data. The operations further include for each sub-rule of the set of sub-rules associated with the at least one firewall rule, determining, using the trained firewall utilization model, a corresponding sub-rule utilization probability indicating a likelihood the sub-rule will be used for a future connection request.

Another aspect of the disclosure provides a computer program product encoded on a non-transitory computer readable storage medium comprising instructions that, when executed by a data processing apparatus, cause the data processing apparatus to perform operations. The operations include receiving firewall utilization data for connection requests received by a firewall during a utilization period, the firewall utilization data including hit counts during the utilization period for each sub-rule of a set of sub-rules associated with at least one firewall rule. The operations also include generating training data based on the firewall utilization data, the training data including unused sub-rules corresponding to sub-rules having no hits during the utilization period and hit sub-rules corresponding to sub-rules having more than zero hits during the utilization period. The operations also include training a firewall utilization model on the training data. The operations further include for each sub-rule of the set of sub-rules associated with the at least one firewall rule, determining, using the trained firewall utilization model, a corresponding sub-rule utilization probability indicating a likelihood the sub-rule will be used for a future connection request.

The operations further include determining firewall attribute groupings for the at least one firewall rule, each of firewall attribute groupings including at least one firewall attribute and determining a first set of sub-rules associated with the at least one firewall rule based on the firewall attribute groupings.

The operations further include receiving a plurality of firewall logs associated with connection requests received by the firewall during the utilization period, filtering the plurality of the firewall logs based on a filter criteria, determining a second set of sub-rules associated with the plurality of firewall logs, and generating the utilization data based on the first set of sub-rules and the second set of sub-rules. In some implementations, the operations further include determining unused firewall rule attributes during the utilization period, for every unused firewall rule attribute, aggregating the sub-rule utilization probabilities for all sub-rules including the unused firewall rule attribute, and determining a probability that a firewall attribute will be hit in the future based on aggregated sub-rule probabilities.

A firewall system enables system administrators to allow or deny traffic from user devices to computing resources, or vice-versa, based on a set of firewall rules. The firewall system includes a set of firewall rules that defines a list of acceptable attributes of user devices requesting to access the computing resources. That is, user devices that satisfy the list of acceptable attributes are permitted access to the computing resources, while user devices that fail to satisfy the list of acceptable attributes are blocked from accessing the computing resources. In most cases, multiple combinations of attributes (e.g., sub-rules) satisfy the list of acceptable attributes defined by the firewall rules. For example, a firewall rule that includes three attribute groupings with each attribute grouping having three acceptable attribute values creates twenty-seven possible attribute combinations (e.g. sub-rules) that satisfy the firewall rule. Here, a user device that includes attribute combinations that match any of the twenty-seven sub-rules satisfies the firewall rule and is permitted to access the computing resources.

Generally, machine learning is the process of implementing statistical techniques to provide computers with the ability to learn without being manually programmed. The computer may be provided with one or more training data sets for building an initial model and/or one or more feedback datasets for adjusting the model. Machine learning may be implemented for predicting future events or outcomes using one or more of the models built based on historical occurrences or patterns. In the context of the instant disclosure, machine learning may be used to optimize firewall configurations by predicting which firewall rules or firewall attributes are likely to be used in future connection requests.

In some implementations, firewall analysis determines which firewall rules are being utilized to access the computing resources and which firewall rules are not being used to access the computing resources. Often times, however, it is difficult to determine the particular attributes and/or sub-rules used to satisfy the firewall rules because any of the multiple attributes and/or sub-rules that exist can satisfy the firewall rule. In particular, firewall rule level analysis may only determine that a firewall rule is being used to access the computing resources, but may not determine exactly which specific attribute and/or sub-rule are used to satisfy the firewall rule. In some instances, the firewall rules include unused attributes that permit access the VMs. For example, the unused attributes may include attributes of user devices permitted to access the computing resources, however, none of the user devices actually accessing the computing resources include the particular unused attribute. Thus, firewall rules that include unused attributes allow broader access to the computing resources than required and may provide a potential future security risk.

Implementations herein are directed towards a method of executing a model to determine sub-rule and attribute level insights of the user devices accessing the computing resources. The sub-rule and attribute level insights provide the firewall system with information regarding which sub-rules and attributes are actually used to access the computing resources. The model predicts the likelihood of the attributes and sub-rules being used in the future based on historical use data. Therefore, the model may accurately determine which attributes and sub-rules of the user devices are no longer needed and can be removed from the firewall rules.

In some implementations, if an ingress allow rule has not been hit for a predetermined utilization period (e.g., <NUM> days), the system reports the probability that this rule will not be hit in the future based on the model. If an ingress allow rule was hit during the utilization period, the system will report if any attributes of this rule (e.g., internet protocol ranges, port ranges, etc.) unused (i.e., zero hits). For those unused attributes, the system will report the probability that they will not be hit in the future based on the model. The system also provides an explanation as to how the prediction is made, e.g., any other similar rules with similar attributes that are also unused.

Referring to <FIG>, in some implementations, an example system <NUM> includes a user device <NUM> associated with a respective user <NUM> and in communication with a cloud network <NUM> via a network <NUM> (e.g., the Internet) and an on-premises network <NUM> (i.e., the local network that the user device <NUM> uses to connect to the network <NUM>). The on-premises network <NUM> includes a network gateway <NUM> (e.g., a router) that serves as the forwarding host for the on-premises network <NUM>. The user device <NUM> may correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (e.g., a smart phone or tablet). The user device <NUM> includes computing resources <NUM> (e.g., data processing hardware) and/or storage resources <NUM> (e.g., memory hardware).

The cloud network <NUM> may be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) having scalable / elastic resources <NUM> including computing resources <NUM> (e.g., data processing hardware) and/or storage resources <NUM> (e.g., memory hardware). A data store (i.e., a remote storage device) may be overlain on the storage resources <NUM> to allow scalable use of the storage resources <NUM> by one or more of the client or computing resources <NUM>. The cloud network <NUM> is configured to implement and execute one or more virtual machines (VMs) <NUM>, 250a-n. One or more of the VMs execute securely in a virtual private cloud (VPC) environment or VPC <NUM> associated with or operated by the user <NUM>. The VPC <NUM> may include a variety of other network elements, such as load balancers, gateways, front ends, and back ends.

In the example shown in <FIG>, the distributed system <NUM> includes a collection <NUM> of resources <NUM> (e.g., hardware resources <NUM>), a virtual machine monitor (VMM) <NUM>, a VM layer <NUM> executing one or more of the VMs <NUM>, and an application layer <NUM>. Each hardware resource <NUM> may include one or more physical central processing units (pCPU) <NUM> ("physical processor <NUM>") and memory hardware <NUM>. While each hardware resource <NUM> is shown having a single physical processor <NUM>, any hardware resource <NUM> may include multiple physical processors <NUM>. An operating system <NUM> may execute on the collection <NUM> of resources <NUM>.

In some examples, the VMM <NUM> corresponds to a hypervisor <NUM> (e.g., a Compute Engine) that includes at least one of software, firmware, or hardware configured to create and execute the VMs <NUM>. A computer (i.e., data processing hardware <NUM>) associated with the VMM <NUM> that executes the one or more VMs <NUM> may be referred to as a host machine, while each VM <NUM> may be referred to as a guest machine. Here, the VMM <NUM> or hypervisor is configured to provide each VM <NUM> a corresponding guest operating system (OS) <NUM> having a virtual operating platform and manage execution of the corresponding guest OS <NUM> on the VM <NUM>. As used herein, each VM <NUM> may be referred to as an "instance" or a "VM instance". In some examples, multiple instances of a variety of operating systems may share virtualized resources. For instance, a first VM <NUM> of the Linux® operating system, a second VM <NUM> of the Windows® operating system, and a third VM <NUM> of the OS X® operating system may all run on a single physical x86 machine.

The VM layer <NUM> includes one or more virtual machines <NUM>. The distributed system <NUM> enables the user <NUM> to launch VMs <NUM> on demand. A VM <NUM> emulates a real computer system and operates based on the computer architecture and functions of the real computer system or a hypothetical computer system, which may involve specialized hardware, software, or a combination thereof. In some examples, the distributed system <NUM> authorizes and authenticates the user <NUM> before launching the one or more VMs <NUM>. An instance of software, or simply an instance, refers to a VM <NUM> hosted on (executing on) the data processing hardware <NUM> of the distributed system <NUM>.

Each VM <NUM> may include one or more virtual central processing units (vCPUs) <NUM> ("virtual processor"). In the example shown, a first virtual machine 250a includes a first set 252a of one or more virtual processors <NUM> and a second virtual machine 250b includes a second set 252b of one or more virtual processors <NUM>. While the second set 252b is shown as only including one virtual processor <NUM>, any number of virtual processors <NUM> is possible. Each virtual processor <NUM> emulates one or more physical processors <NUM>. For example, the first set 252a of the one or more virtual processors <NUM> emulates a first set 204aa of one or more physical processors <NUM>, and the second set 252b of the one or more virtual processors <NUM> emulates a second set 204b of one or more physical processors <NUM>. The application layer <NUM> includes software resources <NUM>, <NUM>10sa, 110sb (software applications) that may execute on the virtual machine(s) <NUM>.

Typically, each instance of software (e.g., a virtual machine <NUM>) includes at least one virtual storage device <NUM> that provides volatile and non-volatile storage capacity for the service on the physical memory hardware <NUM>. For instance, the storage capacity on the physical memory hardware <NUM> can include persistent disks (PD) that store data for the user <NUM> across several physical disks (e.g., memory regions <NUM> (<FIG>) of the memory hardware <NUM> or random access memory (RAM) to provide volatile memory. More specifically, each virtual storage device <NUM> of a corresponding VM <NUM> moves data in sequences of bytes or bits (blocks) to an associated physical block storage volume V on the memory hardware <NUM> to provide non-volatile storage. Accordingly, a virtual storage device <NUM> of a corresponding VM instance <NUM> provides a storage capacity that maps to corresponding physical block storage volumes V on the memory hardware <NUM>. In some examples, the virtual storage devices <NUM> support random access to the data on the memory hardware <NUM> and generally use buffered I/O. Examples include hard disks, CD-ROM drives, and flash drives. Similarly, portions of volatile memory (e.g., RAM) of physical memory hardware <NUM> may be divided across the virtual storage devices <NUM>.

Within the guest operating system <NUM> resides a guest kernel <NUM>. A kernel is a computer program that is the core of the operating system with full access and control over the OS. That is, the kernel is an intermediary between applications <NUM> and the hardware resources <NUM> of the host machine. Most modern computing systems segregate virtual memory into protected kernel space and user space <NUM>. The kernel typically remains in volatile memory within the protected kernel space and is isolated from user space <NUM>. To increase safety and reliability, applications <NUM> and other software services typically execute in the guest user space <NUM> and lack the privileges necessary to interact with the protected kernel space.

Referring back to <FIG>, the cloud network <NUM> may also execute a firewall intelligence module <NUM> including a log processing module <NUM> (<FIG>), machine learning engine <NUM> (<FIG> and <FIG>), and an aggregation module (<NUM>). The firewall intelligence module <NUM> obtains a plurality of firewall logs <NUM> generated by a firewall logger <NUM> of the system. Each of the firewall logs <NUM> corresponds to a connection request <NUM> received from the user device <NUM>. Each firewall log <NUM> includes firewall rules <NUM> associated with the connection request <NUM>.

Referring to <FIG>, the log processing module <NUM> includes a firewall rule determiner <NUM>, a sub-rule generator <NUM>, a firewall log filter <NUM>, a sub-rule mapper <NUM>, and a hit counter <NUM>. The log processing module <NUM> is configured to receive or obtain a first set of the firewall logs <NUM> corresponding to a utilization period (e.g., previous <NUM> days). Using the logs <NUM>, the log processing module <NUM> determines firewall rules <NUM>, sub-rules <NUM>, and attributes <NUM> for the firewall, and then generates utilization data <NUM> including hit counts for the firewall rules <NUM>, sub-rules <NUM>, and/or attributes <NUM>.

The rule determiner <NUM> obtains a plurality of firewall logs <NUM> from the firewall logger <NUM> of the distributed system <NUM> for the predetermined utilization period (e.g., previous <NUM> days). The rule determiner <NUM> is configured to determine firewall rules <NUM> based on the firewall logs <NUM>. The firewall logs <NUM> include information about the connection requests <NUM> from the one or more user devices <NUM> requesting access to the distributed system <NUM>. In particular, the firewall logs <NUM> may include traffic direction (e.g., ingress or egress) of the connection requests <NUM>, firewall rule action (e.g., permit or block) of the connection requests <NUM>, timestamps of the connection requests <NUM>, or any other information about the requests. Each firewall log <NUM> of the plurality of firewall logs <NUM> may be generated in response to a trigger event such as receiving, accepting, and/or denying the connection request <NUM> from a user device <NUM>. The firewall logs <NUM> may also be generated at a set time interval (e.g., hourly, daily, weekly, etc.). The firewall logs <NUM> may be stored in the storage resources <NUM> of the distributed system <NUM> and/or the memory hardware <NUM> of the user device <NUM>.

The rule determiner <NUM> determines, based on the plurality of firewall logs <NUM>, the firewall rules <NUM> that control access to the distributed system <NUM>. The firewall rules <NUM> define attributes <NUM> required by the connection request <NUM> from the user device <NUM> to the distributed system <NUM> in order for the user device <NUM> to access the distributed system <NUM>. The attributes <NUM> of the connection request <NUM> from the user devices <NUM> may be grouped into attribute groupings <NUM>, 314a-d, including a source attribute grouping 314a, a target attribute grouping 314b, a port range attribute grouping 314c, and an IP protocol attribute grouping 314d.

The source attribute grouping 314a defines one or more attributes <NUM> of the source of the connection request <NUM> to access the distributed system <NUM>. For example, a user device <NUM> is the source when the user device <NUM> sends a connection request <NUM> to the distributed system <NUM> to access one of the computing resources <NUM>. Here, each attribute <NUM> of the user device <NUM> represents one of the attributes <NUM> of the source attribute grouping 314a. The attributes <NUM> of the source attribute grouping 214a may include source internet protocol (IP) ranges, source tags, and source service accounts. The firewall rule <NUM> may define one or more attribute values for each attribute <NUM> in the source attribute grouping 314a. For example, an attribute value of the source IP range attribute grouping 314a includes the specific value of the source IP range of the user device <NUM>.

The target attribute grouping 314b defines one or more attributes of the requested target. For example, where a user device <NUM> requests access to a particular computing resource <NUM>, the particular computing resource <NUM> is the target. The target attribute grouping 314b may include attributes <NUM> of target tags and target service accounts. The firewall rule <NUM> may define one or more attribute values for each attribute <NUM> in the target attribute grouping 314b. For example, an attribute value of the target tag attribute may include "receiver" and/or "receiver_tmp. " Optionally, the firewall rule <NUM> may define one or more attribute values of the port range attribute grouping 314c and/or the IP protocol attribute grouping 314d associated with the connection request.

User devices <NUM> that include one or more of the attribute values defined by the attribute groupings <NUM> of the firewall rule <NUM> are allowed to access the computing resources <NUM>. Conversely, user devices <NUM> that do not include attribute values defined by the attribute groupings <NUM> of the firewall rule <NUM> are denied from accessing the computing resources <NUM>. In some examples, the firewall rule <NUM> requires the user devices <NUM> to include a particular combination of the one or more attribute values (e.g., sub-rules <NUM>) to access the computing resources <NUM>. That is, the firewall rule <NUM> may require the user device <NUM> to include attribute values that satisfy one or more of the source attribute grouping 314a, the target attribute grouping 314b, the port range attribute grouping 314c, and/or the IP protocol attribute grouping 314d. In some examples, the rule determiner <NUM> determines multiple firewall rules <NUM> for each firewall log <NUM> in the plurality of firewall logs <NUM>. The rule determiner <NUM> sends each of the firewall rules <NUM> to the sub-rule generator <NUM>.

The sub-rule generator <NUM> is configured to generate all possible sub-rules <NUM> for each of the firewall rules <NUM> using the attribute groupings <NUM>. Each sub-rule <NUM> represents one of the acceptable combinations of attribute values <NUM>, 324a-d defined by the firewall rule <NUM>. For instance an example firewall rule <NUM> may define attribute values <NUM> that includes (i) a source IP range attribute 324a with an allowed attribute values of "<NUM>. <NUM>/<NUM>" or "<NUM>. <NUM>", (ii) a source tag attribute 324a with acceptable attribute values of "sender," (iii) a target tag attribute 324b with acceptable attribute values of "receiver" and "receiver_tmp," and (iv) a port range attribute 324c with acceptable attribute values of "tep:<NUM>-<NUM> and udp:<NUM>". Here, the firewall rule <NUM> defines three attributes 324a in the source attribute grouping 314a (e.g., <NUM>. <NUM>/<NUM>, <NUM>. <NUM>, sender), two attributes 324b in the target attribute grouping 314b (e.g., receiver, receiver_tmp), and two attributes 324c in the port range attribute grouping 314c (e.g., tep: <NUM>-<NUM>, udp:<NUM>) for a total of twelve combinations of attribute values (i.e., <NUM> x <NUM> x <NUM>). Each one of the twelve combinations of acceptable attribute values defines a sub-rule <NUM>. For example, (<NUM>. <NUM>/<NUM>, receiver, and tep:<NUM>-<NUM>) is one of the sub-rules <NUM> and (sender, receiver, and tep:<NUM>-<NUM>) is another one of the sub-rules <NUM> from the twelve possible sub-rules <NUM>. The sub-rule generator <NUM> sends all possible sub-rules <NUM> associated with each of the firewall rules <NUM> to the hit counter <NUM>.

In some examples, the sub-rule generator <NUM> is configured to execute a sub-rule generation function f<NUM> to generate all combinations of sub-rules <NUM> possible for a particularly firewall rule <NUM>. One example implementation of a sub-rule generation function f<NUM> includes a deep nested for-loop enumerating all combinations of sub-rules <NUM> possible for each repeated attribute <NUM> in the firewall rule <NUM>. The sub-rule generation function f<NUM> iterates through each repeated attribute <NUM> in the firewall rule <NUM> and enumerates all sub-rules <NUM> by flattening each repeated attribute <NUM>. A dummy array can be used, containing a single dummy element in case the actual repeated attribute <NUM> is empty to be able to iterate through the attribute <NUM> and generate all the combinations for remaining attributes <NUM> inside the loop.

The firewall log filter <NUM> (referred to herein also as log filter <NUM>) is configured to filter the plurality of firewall logs <NUM> for the utilization period into filtered firewall logs 302F. The log filter <NUM> filters the plurality of firewall logs <NUM> into the subset of filtered firewall logs 302F based on filter criteria <NUM>, 332a-d. The filter criteria <NUM> may include traffic direction 332a (e.g., ingress or egress) of the requests, firewall rule action 332b (e.g., permit or block) of the requests, timestamps 332c of the requests, or any other information 332d about the requests. For example, filter criteria <NUM> that includes ingress traffic direction 332a will filter out all of the firewall logs <NUM> that do not include ingress traffic. The log filter <NUM> allows the user <NUM> or system administrator to filter the plurality of firewall logs <NUM> to only consider firewall logs <NUM> that satisfy a desired filter criteria <NUM>. The log filter <NUM> sends the subset of filtered firewall logs 302F to the sub-rule mapper <NUM>.

The sub-rule mapper <NUM> is configured to determine the sub-rules <NUM>, <NUM> for the filtered firewall logs 302F (e.g., firewall logs of interest) using the same sub-rule generation function f<NUM> as the sub-rule generator <NUM>. Thus, the sub-rule mapper <NUM> evaluates each of the filtered firewall logs 302F to determine which firewall sub-rules <NUM> were used or hit by the corresponding connection request <NUM>. The hit sub-rules <NUM> are the particular sub-rules <NUM> used by the user device <NUM> to access the computing resources <NUM>. That is, each time a user device <NUM> accesses one of the computing resources <NUM> with a particular sub-rule <NUM>, the sub-rule mapper <NUM> marks the particular sub-rule <NUM> as hit. For example, a firewall rule <NUM> defines allowable source tag attributes 324a of "sender" and "sender_tmp" and allowable port range attributes 324c of "tep: <NUM>-<NUM>" and "udp:<NUM>. " In this example, a user device <NUM> that includes the (sender, tep:<NUM>-<NUM>) sub-rule <NUM> is permitted access to the computing resources <NUM>. The sub-rule mapper <NUM> maps the sub-rule <NUM> of (sender, tep: <NUM>-<NUM>) as a hit sub-rule <NUM> because that particular sub-rule <NUM> was used to access the computing resources <NUM>. The sub-rule mapper <NUM> sends each of the hit sub-rules <NUM> for the filtered firewall logs 302F to the hit counter <NUM>.

The hit counter <NUM> is configured to generate utilization data <NUM> including a hit count for each sub-rule <NUM>. In the illustrated example, the hit counter <NUM> generates a utilization data <NUM> for each of the twelve sub-rules <NUM> identified by the sub-rule generator <NUM>. In particular, the hit counter <NUM> receives all possible sub-rules <NUM> from the sub-rule generator <NUM> and the hit sub-rules <NUM> for the filtered firewall logs 302F from the sub-rule mapper <NUM>. Thus, the hit counter <NUM> is able to determine from all the possible sub-rules <NUM> and the hit sub-rules <NUM> which of the sub-rules <NUM> are utilized to access the computing resources <NUM>. The hit counter <NUM> may also generate a count associated with each of the hit sub-rules <NUM>. The count represents the number of times a particular sub-rule <NUM>, <NUM> has been used to access the computing resources <NUM>. The hit counter <NUM> aggregates all of the sub-rules <NUM>, hit sub-rules <NUM>, and counts into the utilization data <NUM>. The hit counter <NUM> may execute at desired periodic intervals to generate new utilization data <NUM>. For example, the hit counter <NUM> may generate the utilization data <NUM> at a temporal interval (e.g., daily) or a volumetric interval (e.g., every <NUM> filtered firewall logs 302F). The hit counter <NUM> may store the utilization data <NUM> in the storage resources <NUM> for training the model <NUM> and/or execution of the model <NUM>.

The firewall intelligence module <NUM> further includes the machine learning engine <NUM> configured to train and execute a firewall utilization model <NUM> to inform and assist network administrators in determining which firewall rules <NUM> or attributes <NUM> are being utilized. Generally, rule-level utilization analysis executed by the firewall intelligence module <NUM> shows which firewall rules <NUM> are being actively used. However, since the sub-rules <NUM> are in OR-relationships with each other, rule-level analysis cannot guarantee that every sub-rule <NUM> is used. Accordingly, there could be rules <NUM> that are broader than necessary, which may allow unwanted requests in the future. In order to detect this problem, the firewall intelligence module <NUM> makes make utilization analysis at a finer level: sub-rules. At the sub-rule level, the firewall intelligence module <NUM> can determine which sub-rules <NUM> are actually hit and consequently which attributes <NUM> are needed.

Although sub-rule level utilization data <NUM> is more useful than rule level data, it is not sufficient to take action on firewall rules <NUM>. For instance, a sub-rule <NUM> might have <NUM> hits on the current day, but may be needed in the future. Therefore even with sub-rule level utilization data <NUM>, it is not easy for network administrators to decide if an existing firewall rule <NUM> needs modification.

To inform and assist the network administrators, the firewall intelligence module <NUM> implements the machine learning engine <NUM> to derive rule-level and attribute-level insights from utilization data <NUM>. The machine learning engine <NUM> can determine the probability that a particular attribute <NUM> will be hit in the future based on historical sub-rule utilization patterns. This way, unneeded attributes <NUM> may be safely deduced and reported to network administrators so that they can make informed decisions to modify the firewall rules <NUM>.

The machine learning engine <NUM> may be implemented as a machine learning engine and includes a prediction module <NUM> (<FIG>) and a training module <NUM> (<FIG>. Generally, the prediction module <NUM> is configured to predict future hit probabilities for unused rules <NUM>, sub-rules <NUM>, and/or attributes <NUM>. Based on the prediction, the prediction module <NUM> outputs training data <NUM> and utilization insights <NUM>, <NUM> for subsequent iterations of the firewall utilization model <NUM>. The training module <NUM> receives the training data <NUM> from the prediction module <NUM> and trains the firewall utilization model <NUM> for use by the prediction module <NUM> in subsequent iterations of determining hit probabilities for unused rules <NUM>, sub-rules <NUM>, and attributes <NUM>.

The prediction module <NUM> includes a training data generator <NUM> that receives the utilization data <NUM> and generates training data <NUM> using the utilization data <NUM>. The training data generator <NUM> converts every sub-rule <NUM> to a feature vector and associates each sub-rule with the labels such as "hit" (hit count > <NUM>) and "unhit" (hit count = <NUM>). The labeled training data <NUM> is used by training module <NUM> to train a new or existing firewall utilization model <NUM>.

Referring to <FIG>, the training module <NUM> receives the labeled training data <NUM> from the training data generator <NUM> and uses the training data <NUM> to build and train one or more firewall utilization models <NUM>. Generally, the training module <NUM> executes a training process to train the firewall utilization model <NUM> on the training data <NUM>. The training process may include implementation of one or more machine learning algorithms and/or statistical analysis for identifying trends or patterns in the training data <NUM>, which can then be used to predict future hits of the firewall sub-rules <NUM>. The training module <NUM> may also utilize machine learning and statistical analysis to tune and/or adjust parameters of the firewall utilization model <NUM>. Here, the training module <NUM> may continuously improve determinations of predicted hits of firewall sub-rules <NUM>. Machine learning may include, for example, supervised learning, unsupervised learning, semi-supervised learning, transduction, reinforcement learning, and other learning algorithms. For example, machine learning algorithms may include AODE, artificial neural networking, Bayesian algorithms, case-based reasoning, decision tree algorithms, Gaussian process regression, regression analysis, fuzzy algorithms, and/or a customized machine learning algorithm including aspects of any machine learning algorithm.

As discussed above, an example firewall sub-rule <NUM> may have seven attributes <NUM>: source range 324a, source tag 324a, source service account 324a, target tag 324b, target service account 324b, port range 324c, and IP protocol 324d. However, for training and inference purposes, the sub-rule <NUM> can be represented as a <NUM>-tuple (source attributes, target attributes, port range attributes) since, at most, one of the three source-related attributes 324a is non-empty and, at most, one of the two target-related attributes 324b is non-empty, by definition.

Some source and target attributes <NUM> are only meaningful for the particular network <NUM> they belong to. These are source tags 324a, source ranges 324a, and target tags 324b. Therefore, when using these attribute values 324a, 324b for inference or training, the training module <NUM> prepends the 'network' identifier to distinguish these attributes <NUM> from the same attributes <NUM> defined in external networks. For example, if the source range is '<NUM>. <NUM>', it is converted to 'network_identifier:<NUM>. But if it is an external source range, like '<NUM>. <NUM>', it is kept as is. If 'source' is empty, it is assumed to be '<NUM>. <NUM>/<NUM>' since an empty source means no limitation on incoming connections. If 'target' is empty, it is assumed to be
'network_identifier:**every_VM_in_network**' (any unique string after the network prefix will do).

At the time of training, the training module <NUM> combines all possible values of the attributes <NUM> observed in the training data <NUM> for 'Source' and 'Target' to create a source-target vocabulary. Similarly, the training module <NUM> creates a port range vocabulary <NUM>. Later, these vocabularies are used to convert string attribute values to one-hot encoded feature vectors. By concatenating these three sparse vectors, the training module <NUM> obtains the feature representation for each sub-rule <NUM>.

In the example of <FIG>, the firewall utilization model <NUM> is illustrated as a neural network. An input layer <NUM> accepts the training data <NUM> explained above. The next layer <NUM> is an embedding layer <NUM>, which maps the feature vector to a lower dimensional feature. An ELU (exponential linear unit) layer <NUM> is configured to capture feature non-linearity. A compute layer <NUM> determines the inner product of the output of the ELU layer <NUM> to create associations between different attributes <NUM>. An output layer of the firewall utilization model <NUM> is a sigmoid that maps the result to a value between <NUM> and <NUM>, which can be interpreted as a future hit probability.

Once the firewall utilization model <NUM> is trained, the training module <NUM> executes a two-step framework to evaluate and validate the performance of the firewall utilization model <NUM>. In an initial step, the firewall utilization model <NUM> is evaluated to ensure that the firewall utilization model <NUM> is ready for use in the production network <NUM> by determining whether the firewall utilization model <NUM> satisfies performance criteria. Once the firewall utilization model <NUM> is implemented in the production network <NUM> (e.g., blocks <NUM>-<NUM> of <FIG>), the firewall utilization model <NUM> is evaluated on a periodic basis (e.g., daily) to determine whether the predicted sub-rule utilization accurately reflects the actual sub-rule utilization. In some implementations, multiple firewall utilization models <NUM> are trained and staged for execution by the machine learning engine <NUM>. Thus, when performance of a current firewall utilization model <NUM> drops below a threshold performance value, the current firewall utilization model <NUM> can be replaced by one of the staged firewall utilization models <NUM>.

With continued reference to <FIG>, the prediction module <NUM> executes the current iteration of the trained firewall utilization model <NUM>. The firewall utilization model <NUM> is configured to predict future hit probabilities for firewall rules <NUM>, sub-rules <NUM>, and attributes <NUM> based on the rule utilization data (e.g., utilization data <NUM>). The future hit probabilities represent the likelihood that the particular firewall rule <NUM>, sub-rule <NUM>, and attribute <NUM> will be used or hit by a connection request <NUM> in the future.

The prediction module <NUM> may include a sub-rule probability generator <NUM>, an attribute probability generator <NUM>, and a rule probability generator <NUM>. The sub-rule probability generator <NUM> is configured to generate a sub-rule utilization probability <NUM> for each of the sub-rules <NUM> based on the utilization data <NUM> and the firewall utilization model <NUM>. That is, based on all of the possible sub-rules <NUM>, the hit sub-rules <NUM>, and the counts associated with the hit sub-rules <NUM>, the sub-rule probability generator <NUM> determines the likelihood of a particular sub-rule <NUM> being hit in the future. In some examples, the sub-rule probability generator <NUM> generates the sub-rule utilization probabilities <NUM> only for unused sub-rules <NUM>. In other examples, the sub-rule probability generator <NUM> generates the sub-rule utilization probabilities <NUM> for all of the possible sub-rules <NUM>. The sub-rule probability generator <NUM> sends the sub-rule utilization probability <NUM> for each of the sub-rules <NUM> to the attribute probability generator <NUM> and the firewall rule probability generator <NUM>.

The attribute probability generator <NUM> is configured to generate an attribute probability <NUM> that represents the likelihood of a particular attribute <NUM> for the firewall rule <NUM> being used in the future. The attribute probability generator <NUM> generates the attribute probability <NUM> based on the aggregation of sub-rule utilization probabilities <NUM>. That is, for every attribute <NUM> that is unused during the utilization period, the attribute probability generator <NUM> aggregates the sub-rule utilization probabilities <NUM> of all the sub-rules <NUM> that include the particular attribute <NUM>. The attribute utilization probability <NUM> may be represented by: <MAT>.

In equation <NUM>, P(attributevalue) represents the probability <NUM> that the particular attribute <NUM> will be used, P(subrule<NUM>) represents the probability that the first sub-rule <NUM> that includes the particular attribute <NUM> will not be used, and P(subrulen) represents the probability that the nth sub-rule <NUM> that includes the particular attribute <NUM> will not be hit. Thus, by aggregating each of the sub-rule utilization probabilities <NUM> for sub-rules <NUM> that include a particular attribute <NUM>, the attribute probability generator <NUM> determines the probability <NUM> that a particular attribute <NUM> will be used in the future. The attribute probability generator <NUM> sends each of the attribute utilization probabilities <NUM> to the attribute comparer <NUM>.

The attribute comparer <NUM> is configured to identify attributes <NUM> that are similar to each unused attribute (i.e., attributes with zero hits). Particularly, for each of the attributes <NUM>, the attribute comparer <NUM> determines a similarity score <NUM> that represents the similarity between a particular attribute <NUM> and one of the unused attributes <NUM>. The attribute comparer <NUM> determines the attribute similarity score <NUM> by comparing the attribute utilization probabilities <NUM> of each of the attributes <NUM>. In particular, the attribute comparer <NUM> determines that attributes <NUM> that include similar attribute probabilities <NUM> include similar attribute information.

In some examples, the prediction module <NUM> may determine, based on the attribute probabilities <NUM> and similarity scores <NUM>, attributes <NUM> that can be eliminated from the firewall rules <NUM>. For example, attributes <NUM> that include attribute probabilities <NUM> that fail to satisfy a threshold value may be eliminated from the firewall rules <NUM> because of the low likelihood of being hit in the future. In another example, attributes <NUM> that include similarity scores <NUM> that satisfy a threshold value may be eliminated because the attribute <NUM> is a duplicate of another attribute <NUM>. That is, the attribute <NUM> may be similar enough to another one of the attributes <NUM> that the attribute <NUM> does not need to be included in the firewall rules <NUM>. The similarity scores <NUM> and attribute probabilities <NUM> may be stored as unused attribute insights <NUM>, which can be used by the network administrator to modify attributes <NUM>.

The rule probability generator <NUM> is configured to generate a rule probability <NUM> that represents the likelihood of each of the firewall rules <NUM> being hit in the future. That is, for every firewall rule <NUM> that is unused during the utilization period, the rule probability generator <NUM> aggregates the sub-rule utilization probabilities <NUM> of all possible sub-rules <NUM> for the firewall rule <NUM>. The firewall rule probability <NUM> may be represented by: <MAT>.

In equation <NUM>, P(rule) represents the probability that the firewall rule will be used, P(subrule<NUM>) represents the probability that the first sub-rule <NUM> of the firewall rule <NUM> will not be used, and P(subrulen) represents the probability that the nth sub-rule <NUM> of the firewall rule <NUM> will not be used. The firewall rule probability generator <NUM> sends each of the rule probabilities <NUM> to the firewall rule comparer <NUM>.

The firewall rule comparer <NUM> is configured to find rules <NUM> that are similar to each unused rule <NUM>. Particularly, for each of the firewall rules <NUM>, the firewall rule comparer <NUM> determines a rule similarity score <NUM> by comparing attributes <NUM> between firewall rules <NUM>. The firewall rule comparer <NUM> determines that firewall rules are similar when the firewall rules have a threshold number of attributes <NUM> in common, resulting in a high rule similarity score <NUM> for the respective firewall rules <NUM>. The rule probability generator <NUM> and the rule comparer <NUM> compile and store the respective rule probabilities <NUM> and the rule similarity scores <NUM> as unused rule insights <NUM>. Collectively, the unused rule insights <NUM> and the unused attribute insights <NUM> may be referred to as utilization insights <NUM>, <NUM>.

Referring back to <FIG>, the firewall intelligence module <NUM> may also include an aggregation module <NUM> (<FIG>) configured to aggregate recommended firewall configurations provided by each of the prediction module <NUM> (i.e., using the trained firewall utilization model <NUM>) and a reachability module <NUM> operating independent of the machine learning engine <NUM>. For example, the reachability module <NUM> provides reachability insights <NUM> related to shadowed firewall rules <NUM> (i.e., rules overlapping with other rules) and unused firewall rules <NUM> that have not been hit for a period of time (e.g., <NUM> days), while the machine learning engine <NUM> provides utilization insights <NUM>, <NUM> predicting the probability that unused rules <NUM> or attributes <NUM> will be used in the future.

The different types of insights <NUM>, <NUM>, <NUM> may result in conflicts. For example, the utilization insights <NUM>, <NUM> generated by the prediction module <NUM> include sub-rules <NUM> for all firewall rules <NUM>, which may need to be modified to filter out unused and shadowed rules identified by the reachability insights <NUM>. Additionally, some of the rules <NUM> may have overlapping behavior where they are shadowed and unused. These overlapping rules <NUM> may need to be combined.

As shown in <FIG>, a reachability analyzer <NUM> of the aggregation module <NUM> polls a reachability module <NUM> to obtain reachability insights <NUM>, which include unused rule insights 542a and shadowed rule insights 542b. A utilization analyzer <NUM> obtains the utilization insights <NUM>, <NUM> generated by the machine learning engine <NUM>. A rule aggregator <NUM> then groups all of the insights <NUM>, <NUM>, <NUM> based on the firewall rules <NUM>. In one configuration, the rule aggregator <NUM> groups the insights <NUM>, <NUM>, <NUM> by ranking the different insights <NUM>, <NUM>, <NUM> using a particular ranking criteria, such as shadowed rules > unused rules > sub-rule utilization. The aggregation module <NUM> then presents the top-ranked insight <NUM>, <NUM>, <NUM> for each firewall rule <NUM> to the system administrator as firewall configuration recommendations <NUM>. Accordingly, where a firewall rule <NUM> includes a shadow insight <NUM> and a utilization insight <NUM>, the rule aggregator <NUM> may only generate the firewall configuration recommendations <NUM> based on the shadow insight <NUM>. While the aggregation module <NUM> is shown in <FIG> as being incorporated as part of the firewall intelligence module <NUM>, the aggregation module <NUM> may be executed independently of the firewall intelligence module <NUM>.

<FIG> is a flowchart of an exemplary arrangement of operations for a method <NUM> of processing firewall insights using machine learning. The method <NUM> includes, at operation <NUM>, receiving firewall utilization data <NUM> for connection requests <NUM> received by a firewall during a utilization period, the firewall utilization data <NUM> including hit counts during the utilization period for each sub-rule <NUM> of a set of sub-rules <NUM> associated with at least one firewall rule. At operation <NUM>, the method <NUM> includes generating training data <NUM> based on the firewall utilization data <NUM>, the training data <NUM> including unused sub-rules <NUM> corresponding to sub-rules <NUM> having no hits during the utilization period and hit sub-rules <NUM> corresponding to sub-rules <NUM> having more than zero hits during the utilization period. The method <NUM> also includes, at operation <NUM>, training a firewall utilization model <NUM> on the training data <NUM>. At operation <NUM>, the method <NUM> includes for each sub-rule <NUM> of the set of sub-rules <NUM> associated with the at least one firewall rule, determining, using the trained firewall utilization model <NUM>, a corresponding sub-rule utilization probability <NUM> indicating a likelihood the sub-rule <NUM> will be used for a future connection request <NUM>.

For example, it may be implemented as a standard server 700a or multiple times in a group of such servers 700a, as a laptop computer 700b, or as part of a rack server system 700c.

Claim 1:
A computer-implemented method (<NUM>) when executed on data processing hardware (<NUM>) causes the data processing hardware (<NUM>) to perform operations for training a firewall utilization model (<NUM>), the operations comprising:
receiving (<NUM>) firewall utilization data (<NUM>) for connection requests (<NUM>) received by a firewall during a utilization period, the firewall utilization data (<NUM>) including hit counts during the utilization period for each sub-rule of a set of sub-rules (<NUM>) associated with at least one firewall rule (<NUM>);
generating (<NUM>) training data (<NUM>) based on the firewall utilization data (<NUM>), the training data (<NUM>) including unused sub-rules (<NUM>) corresponding to sub-rules (<NUM>) having no hits during the utilization period and hit sub-rules (<NUM>) corresponding to sub-rules (<NUM>) having more than zero hits during the utilization period;
training (<NUM>) the firewall utilization model (<NUM>) on the training data (<NUM>);
for each sub-rule of the set of sub-rules (<NUM>) associated with the at least one firewall rule (<NUM>), determining (<NUM>), using the trained firewall utilization model (<NUM>), a corresponding sub-rule utilization probability (<NUM>) indicating a likelihood the sub-rule will be used for a future connection request (<NUM>);
determining firewall attribute groupings (<NUM>) for the at least one firewall rule (<NUM>), each of firewall attribute groupings (<NUM>) including at least one attribute (<NUM>);
determining a first set of the sub-rules (<NUM>) associated with the at least one firewall rule (<NUM>) based on the firewall attribute groupings (<NUM>);
receiving a plurality of firewall logs (<NUM>) associated with connection requests (<NUM>) received by the firewall during the utilization period;
filtering the plurality of the firewall logs (<NUM>) based on a filter criteria (<NUM>);
determining a second set of sub-rules (<NUM>) associated with the plurality of firewall logs (<NUM>); and
generating the utilization data (<NUM>) based on the first set of sub-rules (<NUM>) and the second set of sub-rules (<NUM>).