Serialization of firewall rules with user, device, and application correlation

Distributed firewalls reside at different points across a network. Each distributed firewall can include one or more rules that govern traffic over and/or access to the network. The rules can be discovered, converted into a standardized format, and indexed at a centralized rule database. The rules or data of the rules can be verified. The rules can be certified at the centralized database. The certification process can be based on a direction of traffic to which the rule governs. The certification process may have different levels based on the direction of traffic.

BACKGROUND

Distributed networks call for detailed management of a variety of factors. Managing what and/or who has access to an internal network, such as for a business, is often time intensive and complicated. Firewall rules dictate and grant access on an individual user, device, and/or application basis. Further, it is difficult to identify what user, device, and/or application may be utilizing a given firewall rule as well running analysis against large-scale firewall deployments. It is also difficult to certify rules may each govern different types of traffic.

BRIEF DESCRIPTION

Distributed firewalls reside at different points across a network. Each distributed firewall can include one or more rules that govern traffic over and/or access to the network. The rules can be discovered, converted into a standardized format, and indexed at a centralized rule database. The rules or data of the rules can be verified. The rules can be certified at the centralized database. The certification process can be based on a direction of traffic to which the rule governs. The certification process may have different levels based on the direction of traffic.

In aspects, the subject innovation provides substantial benefits in terms of firewall management and servicing. One advantage resides in a more standardized index of firewall rules and/or policies. Another advantage resides in real time or near real time updating and monitoring and vice versa of new and old firewall rules. Another advantage resides in a robust certification process.

DETAILED DESCRIPTION

Distributed firewalls reside at different points across a network. Each distributed firewall can include one or more rules that govern traffic over and/or access to the network. The rules can be discovered, converted into a standardized format, and indexed at a centralized rule database. The rules or data of the rules can be verified. The rules can be certified at the centralized database. The certification process can be based on a direction of traffic to which the rule governs. The certification process may have different levels based on the direction of traffic.

Various aspects of the subject disclosure are now described in more detail with reference to the annexed drawings, wherein like numerals generally refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to incorporate all modifications, equivalents, and alternatives falling within the spirit and scope of this specification and claims appended hereto.

FIG. 1illustrates an overview system100for serializing firewall rules. The system100includes a management component110. The management component110resides or interacts with an enterprise network120such as a corporation wide network, intranet, and/or the like. In some embodiments, the enterprise network120can be a corporation wide network that provides online services and/or access to corporate sites and/or information.

The management component110accesses at least one firewall130on the enterprise network120. In some embodiments, there is more than one firewall managed by an entity throughout the enterprise network1210. Typically, a firewall is managed by one or more network administrators. The at least one firewall130may be distributed across the enterprise network120and interact with the network to control access. The management component110discovers or mines the at least one firewall130across the network for firewall rules. For example, the at least one firewall130can include rule A140and/or rule B150. The management component110can use data mining algorithms, searching algorithms, and/or the like.

The firewall rules (rule A140, rule B150) from the at least one firewall130determine what is allowed access to the enterprise network120and/or what type of traffic is allowed. The firewall rules (rule A140, rule B150) from the at least one firewall130control access for internal and/or external users of the network. In some embodiments, rule A140can manage access to the enterprise network120for an external traffic source A150and rule B150can manage access to the enterprise network120for an external traffic source B160.

Further, The firewall rules (rule A140, rule B150) from the at least one firewall130can control access to different parts of the enterprise network120such that only part of the network may be available to certain users and/or applications. The firewall rules (rule A140, rule B150) from the at least one firewall130can be divided according to geographic area, applications, users, user types, and/or a combination thereof, among others.

The management component110discovers firewall rules (rule A140, rule B150) from the at least one firewall130. The management component110discovers data of the firewall rules (rule A140, rule B150) and stores the data of the firewall rules (rule A140, rule B150) in a rule database180. The management component110can connect to a mobile network, wired LAN, wireless LAN, an internet network, or the like to transmit communications. The management component110connects to a transmission server to send and receive data, alerts, or the like to and from networked devices. In one embodiment, the mode of the communication can be an application programming interface (API), and/or the like. The management component110accesses the at least one firewall130over the enterprise network120. In the case of multiple firewalls, the management component110accesses each firewall individually, i.e. 1 . . . N, and discovers existing firewall rules from each firewall. The rules can be stored in a rule database180.

In one embodiment, the management component110monitors the at least one firewall130for newly created firewall rules. The management component110detects a newly created firewall rule at the at least one firewall130. The management component110discovers the new firewall rule and communicates the rule for storage at the rule database180.

In some embodiments, firewall rules can contain mostly the same data. In other embodiments, different firewalls can dictate firewall rules in different formats. For example, the firewall rule format can vary by firewall manufacturer. The management component110converts a firewall rule in a different format into a conventional or standardized format that can be parsed or indexed.

The management component110performs operations on the firewall rules or manipulates data of the firewall rules. The management component110mines each firewall rule for data to be indexed in the rules database180. The management component110populates data fields of the database, the fields being data categories belonging to each firewall rule. For example, the data and/or data fields can be rule name, source, destination, services, last usage date, hit count, last certification date, last certification status, and/or the like.

The management component110creates data-tags for each rule in the rule database180. The management component110parses the data in each data field. The management component110converts the parsed data into data-tags, e.g. text strings that can be logged and keyword searched. The data-tags can be searchable such that rules in the rule database180can be easily found according to search criteria. For example, a user can search for all rules with the same destination IP address.

The management component110determines assets that are associated with each rule. The management component110accesses other data sources, e.g. other network information/sources or the like, to associate a firewall rule to a source, e.g. an application. For example, the management component110can include an asset database or be in communication with an asset database residing elsewhere on the network. The asset database can include a device IP address associated with a device of a user. The device IP address can be associated or matched to a source IP address of a rule in the rule database180to determine ownership of the rule. The rule will be associated with the specific user device in the rule database180.

In another example, the management component110can read data packets, domain name system (DNS) data, net mask data, and/or network traffic to correlate an application and a firewall rule. The management component110can access a data log or monitor traffic for source IP addresses and destination IP addresses. The management component110can discover the application that is generating the network traffic. The management component110associates the application's generated network traffic read by the management component110that has the same source and destination IP addresses as a firewall rule to determine ownership of that rule. The determined ownership of a rule is stored in the rule database180in an asset data field and can be data-tagged by the management component110.

The management component110determines whether the source or owner using a particular rule, e.g. the source IP address or an owner associated with a source IP address, is authenticated. The management component110can obtain 3rdparty verification of the rule from an owner. In one embodiment, the management component110can generate a 1-time code. The management component110sends the 1-time code to the owner over a transmission server having a processor and a memory to a user device. The owner receives the 1-time code on the user device and responds with the code either over the transmission server or at the distributed firewalls220. The management component110receives the 1-time code back from the owner over the transmission server from the user device. The management component110determines the sent 1-time code and the received 1-time code match. It is appreciated that this is just one specific example of 3rd party authentication. Other forms of owner authentication are contemplated, such as, but not limited to, voice recognition, image recognition, fingerprint recognition, biometric recognition, and/or the like.

In one embodiment, a network administrator can review each firewall rule in the rule database180. In other embodiments, verification may be automated to verify the extracted information for correctness and currency. The review can be at time of creation or a periodic review by the network administrator. The management component110can include a user interface to receive user input for manipulating or changing data in a data field. The network administrator can make changes to a rule via the management component110. The network administrator can create a comments data field to attach notes about a particular rule. The network administrator can modify operative parts of a rule in a respective data field. For example, the network administrator can change the destination IP address of a rule in the rule database180via the management component110. The management component110can receive the change in the firewall rule and make the change at the at least one firewall130over the network such that it becomes operative at the firewall. A detailed verification process is described below.

FIG. 2illustrates a system200for serializing firewall rules depicted with a detailed component diagram of the management component110. In some embodiments, the management component110resides or interacts with a network such as a corporation wide network and/or intranet.

The management component110includes a discovery component210. The discovery component210accesses one or more distributed firewalls220. The distributed firewalls220are a system of firewalls managed by an entity throughout a network. Typically, a firewall is managed by one or more network administrators. The distributed firewalls220are distributed across a network and interact with the network to control access. The distributed firewalls220determine what is allowed access to the network or what type of traffic is allowed. In one embodiment, the network can be a corporation wide network that provides online services and/or access to corporate sites and/or information. The firewalls control access for internal and/or external users of the network. Further, the firewalls can control access to different parts of the network such that only part of the network may be available to certain users and/or applications. The firewalls can be divided according to geographic area, applications, users, user types, and/or a combination thereof, among others.

The discovery component210discovers or mines the distributed firewalls220across the network for firewall rules. The discovery component210can use data mining algorithms, searching algorithms, and/or the like. The distributed firewalls220are accessed individually by the discovery component210. For example, the discovery component210accesses Firewall1230, Firewall2240, to FirewallN250of the distributed firewalls220. Each firewall, i.e. 1 . . . N, has a set of firewall rules, e.g. policies, stored locally at the firewall.

The discovery component210discovers firewall rules from each firewall of the distributed firewalls220. The discovery component210discovers the firewall rules and stores the firewall rules in a rule database180. With reference toFIG. 3, the discovery component210includes a communication component310. The communication component310can connect to a mobile network, wired LAN, wireless LAN, an internet network, or the like to transmit communications. The communication component310connects to a transmission server to send and receive data, alerts, or the like to and from networked devices. In one embodiment, the mode of the communication can be an application programming interface (API), and/or the like. The communication component310accesses the distributed firewalls220over the network. The communication component310accesses each firewall individually, i.e. 1 . . . N, and discovers existing firewall rules from each firewall. The discovered rules170can be stored in a rule database180.

In one embodiment, the communication component310monitors the firewall for newly created firewall rules. The communication component310detects a newly created firewall rule at a distributed firewall. The communication component310discovers the new firewall rule and communicates the rule for storage at the rule database180.

In one embodiment, the discovery component210includes a mapping component320. Typically, firewall rules contain mostly the same data; however, different firewalls can dictate firewall rules in different formats. For example, the firewall rule format can vary by firewall manufacturer. The mapping component320converts a firewall rule in a different format into a conventional or standardized format that can be parsed or indexed.

The discovery component210includes an analysis component330. The analysis component330performs operations on the firewall rules or manipulates data of the firewall rules. With reference toFIG. 4and continuing reference toFIG. 3, the analysis component330includes an index component410. The index component410mines each firewall rule for data to be indexed in the database. The index component410populates data fields of the database, the fields being data categories belonging to each firewall rule. For example, the data and/or data fields can be rule name, source, destination, services, last usage date, hit count, last certification date, last certification status, and/or the like.

The analysis component330includes a sorting component420. The sorting component420creates data-tags for each rule in the rule database180. The sorting component420parses the data in each data field. The sorting component420converts the parsed data into data-tags, e.g. text strings that can be logged and keyword searched. The data-tags can be searchable such that rules in the rule database180can be easily found according to search criteria. For example, a user can search for all rules with the same destination IP address.

The analysis component330includes an association component430. The association component430determines assets that are associated with each rule. With reference toFIG. 5, the association component430accesses other data sources, e.g. other network information/sources or the like, to associate a firewall rule to a source, e.g. an application. For example, the association component can include an asset database510or be in communication with an asset database residing elsewhere on the network. The asset database510can include a device IP address associated with a device of a user. The device IP address can be associated or matched to a source IP address of a rule in the rule database180to determine ownership of the rule. The rule will be associated with the specific user device in the rule database180.

In another example, the association component430includes a traffic component520. The traffic component520can read data packets, domain name system (DNS) data, net mask data, and/or network traffic to correlate an application and a firewall rule. The traffic component520can access a data log or monitor traffic for source IP addresses and destination IP addresses. The traffic component520can discover the application that is generating the network traffic. The association component430associates the application's generated network traffic read by the traffic component520that has the same source and destination IP addresses as a firewall rule to determine ownership of that rule. The determined ownership of a rule is stored in the rule database180in an asset data field and can be data-tagged by the sorting component420.

With continuing reference toFIG. 4, the analysis component330includes a verification component440. The verification component440determines whether the source or owner using a particular rule, e.g. the source IP address, is authenticated. The verification component440can obtain 3rd party verification of the rule from an owner associated with the source and/or firewall rule. In one embodiment, the verification component440can generate a 1-time code. The verification component440sends the 1-time code to the owner over a transmission server450having a processor and a memory to a user device460. The owner receives the 1-time code on the user device460and responds with the code either over the transmission server450or at the distributed firewalls220. The verification component440receives the 1-time code back from the user over the transmission server450from the user device460. The verification component440determines the sent 1-time code and the received 1-time code match. It is appreciated that this is just one specific example of 3rd party authentication. Other forms of authentication are contemplated, such as, but not limited to, voice recognition, image recognition, fingerprint recognition, biometric recognition, and/or the like.

With continuing reference toFIG. 1, in one embodiment, a network administrator can review each firewall rule in the rule database180to verify the extracted information for correctness and currency. The review can be at time of creation or a periodic review by the network administrator. The management component110can include a user interface260to receive user input for manipulating or changing data in a data field. The network administrator can make changes to a rule via the user interface260of the management component110. The network administrator can create a comments data field to attach notes about a particular rule. The network administrator can modify operative parts of a rule in a respective data field. For example, the network administrator can change the destination IP address of a rule in the rule database180via the user interface260. The management component110can receive the change in the firewall rule and make the change at the distributed firewalls220over the network such that it becomes operative at the firewall.

With reference toFIG. 6, an example input/output diagram600is depicted for a firewall rule in a distributed firewall processed into a rule database. The input to the system begins with a firewall rule602. The firewall rule is passed to a rule serializer604. The rule serializer604divides the firewall rule602into smaller data parcels606. The data parcels606for a firewall rule602can include a source, a destination, and services. The source can be a starting IP address where network data packets are originated. The destination can be an end IP address where network data packets are directed towards. The service can be the type of network data that can be allowed or denied by the firewall to a network.

Typically, firewall rules include objects. The firewall rule602can be parsed into objects, e.g. portions of function data, which define how the firewall rule602operates in the firewall. Objects can be classified by object type608. The object type608can be categorized according to function. Object types608can be a network object610, a service object612, and/or a group614. A network object610can define a host, a range of IP addresses, a network IP address, and/or other. The network object610is mapped616to NetworkObject DataFields618. The NetworkObject DataFields618are standardized data fields that can be uniform for each rule in a rule database. The NetworkObject DataFields618include Name, IPAddress, NetMask, IPAddrStart, IPAddrEnd, Type, among others.

Some objects may not translate directly into each data field. The system can follow a mapping rubric or logic to map object data to an appropriate data field. For example, a host network object includes only one IP address for a host. In the example, the host IP address is mapped616to both the IPAddrStart and IPAddrEnd data fields. In another example, a range of IP addresses network object includes a sequential list of IP addresses with a start and an end. The start and end of the range of IP addresses can be mapped616to the IPAddrStart and IPAddrEnd data fields respectively. In yet another example, a network IP address object includes an IPAddr/NetMask and a NetMask. The IPAddr/NetMask can be mapped616to IPAddrStart and IPAddrEnd data fields, and the NetMask is mapped to the NetMask data field. In another example, another network object includes properties that can be parsed and populate the Network Object DataFields618.

A service object612includes properties that can be mapped616to ServiceObject DataFields620. ServiceObject DataFields620can include data fields such as name, port, protocol, type, and/or the like. A group617can be mapped616to a GroupHierarchy622. The GroupHierarchy622can include data fields such as parent, child, and/or the like.

For network objects610, the NetworkObject DataFields618are passed to an association engine624. In particular, the IPAddrStart and IPAddrEnd data fields can be passed to the association engine624. The association engine624determines an asset associated with the network object610. An asset can be an application, user device, account, and/or the like. The association engine624accesses an asset configuration management database (CMDB)626. The asset CMDB626includes DNS entries and/or other asset IP SOR information. The association engine624associates the IPAddrStart and IPAddrEnd data fields to an asset IPAddress data field in the asset CMDB626. The association engine624can determine628whether the asset IP address is within range of the IPAddrStart and IPAddrEnd to determine an association. If within range, an association is created between the network object610or firewall rule602and the asset. The NetworkObject DataFields618, ServiceObject DataFields620, and/or GroupHiearchy622are stored in a Firewall Rule-Asset Database630. The Firewall Rule-Asset Database630associates the data fields with the firewall rule602and the determined relationship between the asset and the firewall rule602.

With reference toFIG. 7, an example method700is depicted for customer verification of firewall rules. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, e.g., in the form of a flow chart, are shown and described as a series of acts, it is to be understood and appreciated that the subject innovation is not limited by the order of acts, as some acts may, in accordance with the innovation, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the innovation. It is also appreciated that the method700is described in conjunction with a specific example is for explanation purposes.

In aspects, method700can begin at710by accessing firewalls that are distributed across a network. Firewall rules are stored locally at each firewall location. For example, a firewall rule residing at a distributed firewall dictates a user device having access to only user account server on the corporate network and not elsewhere on the network. The firewall rule can limit traffic to only data packets that have a source IP address of the user device and a destination IP address of the user account server. At720, the firewall rules are extracted from each distributed firewall. The firewall rules can be accessed and discovered via an API call and response and/or the like. The firewall rules are extracted to a database. The database can be networked or offline. Continuing the example, the firewall rule is copied at the distributed firewall and stored in the database. At730, the firewall rules are indexed. The firewall rules are parsed for data. The data is indexed into data fields of a database entry. In the example, the firewall rule is divided into data fields. The data fields for this specific example can be a rule name, the source IP address, and/or the destination IP address.

At740, searchable data-tags are created for the firewall rules. The data in each data-field is parsed into text that can be searchable within the database. In the example, the source IP address data field can be parsed and tagged such that it is searchable in the database. The destination IP address and/or the name data fields can be parsed and tagged accordingly. In one embodiment, the IP addresses can be converted to binary to facilitate searching. At750, the firewall rules can be matched to assets of the rules. For example, an asset can be a user, application, device, and/or the like. Each rule can be associated with an asset. A data-field in the database entry for a particular rule is created and populated with a determined asset. The ownership data-field can be tagged and made searchable in the database. In the example, the asset of the rule can be the user account associated with the user device, or the user device itself. The source IP address and destination IP address can be matched to known source IP address and destination IP address in the user account server as belonging to a particular user account. The user account is associated with the firewall rule in the database.

At760, the asset can be verified. In some embodiments, to verify a user as an asset, the verification can use 3rdparty verification to authenticate the user. The verification can be a 1-time code sent to a user device, voice recognition, image recognition, fingerprint recognition, biometric recognition, and/or the like. For example, the associated user account can include a user phone number. A 1-time code can be sent to the user phone number. A user can input the 1-time code in the network when accessing the user account server to verify the association with the rule.

FIG. 8illustrates a further embodiment of a system800for certifying firewall rules. The system800includes a discovery component810. The discovery component810discovers a firewall rule from at least one firewall over a network using a search algorithm. The discovery component810accesses distributed firewalls as described above. The distributed firewalls are a system of firewalls managed by an entity throughout a network. Typically, a firewall is managed by one or more network administrators. The distributed firewalls are distributed across a network and interact with the network to control access. The distributed firewalls determine what is allowed access to the network or what type of traffic is allowed. In one embodiment, the network can be a corporation wide network that provides online services and/or access to corporate sites and/or information. The firewalls control access for internal and/or external users of the network. Further, the firewalls can control access to different parts of the network such that only part of the network may be available to certain users and/or applications. The firewalls can be divided according to geographic area, applications, users, user types, and/or a combination thereof, among others.

The discovery component810discovers or mines the distributed firewalls across the network for firewall rules. The discovery component810can use data mining algorithms, searching algorithms, and/or the like. The distributed firewalls can be accessed individually by the discovery component810. For example, the discovery component810accesses Firewall1, Firewall2, to FirewallNof the distributed firewalls. Each firewall, i.e. 1 . . . N, has a set of firewall rules, e.g. policies, stored locally at the firewall. The discovery component210discovers firewall rules from each firewall of the distributed firewalls.

The system800includes a classification component820. In some embodiments, the classification component820classifies the firewall rule based on a direction of traffic. A direction of traffic can be inbound traffic, outbound traffic, or exclusively internal traffic. Inbound traffic is network traffic that originates from an external source on an outside network and is being sent to an internal source on the network. Outbound traffic is network traffic that originates from an internal source on the network and is being sent to an external source on an outside network.

In some embodiments, the classification component820determines the firewall rule allows inbound traffic from external sources. The external sources reside on an outside network. The classification component820can determine information about the firewall rule. The classification component determines whether the firewall rule has been tagged as a publicly accessible application. If a publicly accessible application tag exists, the firewall rule is certified according a standard certification and/or validation process. If a publicly accessible application tag does not exist, a detailed certification and/or validation process is triggered. The classification component820creates a publicly accessible application tag for the firewall rule based on the determination of inbound traffic.

The system800includes a communication component830. The communication component830requests a detailed certification of the firewall rule. In some embodiments, the communication component830generates and sends a notification for the firewall rule based on the publicly accessible application tag. The notification requests a detailed certification of the firewall rule. In some embodiments, the notification is sent to a firewall rule owner, network administrator, and/or the like. In other embodiments, the notification is sent to a publicly accessible application board or a certification board.

In some embodiments, the system800includes a certification component840. The certification component840certifies the firewall rule based on the direction of traffic. If the firewall rule does not include a publicly accessible application tag, the certification component840determines an owner of the firewall rule. The certification component840requests an acknowledgement of the publicly accessible application tag for the firewall rule from the owner. The owner can approve or deny the publicly accessible application tag. If the owner approves of the tag, the approval is sent to a certification board. The certification component840receives approval of the firewall rule from the certification board. If the owner denies the tag, the certification component840queries the owner to provide reasons and sends the reasons to the certification board. The certification component840can receive approval of the tag from the certification board. If approved, the firewall rule is certified according a standard certification and/or verification/validation process.

If the firewall rule exclusively allows traffic from internal sources, or has been certified during the detailed certification, the firewall rule can be verified in a standard process (e.g. a less rigorous process). In some embodiments, the certification component840and/or a verification component verifies the firewall rule from an asset of the firewall rule. The certification component840determines whether the source using a particular rule, e.g. the source IP address, is authenticated. The certification component840can obtain 3rdparty verification of the ownership of a rule from the owner. In one embodiment, the certification component840can generate a 1-time code. The certification component840sends the 1-time code to the owner over a transmission server having a processor and a memory to a user device. The owner receives the 1-time code on the user device and responds with the code either over the transmission server or at the distributed firewalls. The certification component840receives the 1-time code back from the owner over the transmission server from the user device. The certification component840determines the sent 1-time code and the received 1-time code match. It is appreciated that this is just one specific example of 3rdparty authentication. Other forms of authentication are contemplated, such as, but not limited to, voice recognition, image recognition, fingerprint recognition, biometric recognition, and/or the like.

FIG. 9illustrates a method900. At902, the firewall rule is determined to allow inbound traffic from external sources. The external sources reside on an outside network. At904, the firewall rule is analyzed to determine to whether the rule has been tagged as a publicly accessible application. If a publicly accessible application tag exists, at906, the firewall rule is certified according a standard certification and/or validation process.

If a publicly accessible application tag does not exist, a detailed certification and/or validation process is triggered. At908, if the firewall rule does not include a publicly accessible application tag, an application owner of the firewall rule is determined and/or confirmed. If the application does not own the firewall rule, at910, a certifier or certification component can select “not mine.” At912, a “not mine” process is applied. At914, a check is performed for other firewall rules that are determined to receive detailed certification. If yes, the method returns to908for the remaining rules. If no, at906, the firewall rule is certified according a standard certification and/or validation process.

If the ownership for the firewall rule is confirmed, at916, an acknowledgement that the owner uses the firewall rule is requested. If no, the method returns to908to follow the “not mine” procedure described. If yes, at918, an acknowledgement of the publicly accessible application tag for the firewall rule is requested from the certifier and/or certification component. The owner can approve or deny the publicly accessible application tag. If the owner approves of the tag, at920, the approval is sent to a certification board. If the owner denies the tag, at922, the certifier and/or certification component provides and sends reasons to the certification board at920. At920, a signal is sent to the certification board for final approval of the publicly accessible application tag. If approved, at906, the firewall rule is certified according a standard certification and/or verification/validation process.

A method for serializing firewall rules, comprising: discovering, by a processor, a firewall rule from at least one firewall over a network using a search algorithm; storing the firewall rule in a rule database remote from the firewall; classifying the firewall rule based on a direction of traffic; and certifying the firewall rule based on the direction of traffic.

A system, comprising: a discovery component that discovers, by a processor, a firewall rule from at least one firewall over a network using a search algorithm; a classification component that classifies the firewall rule based on a direction of traffic; and a certification component that certifies the firewall rule based on the direction of traffic.

A computer readable medium having instructions to control one or more processors configured to: discover, by a processor, a firewall rule from at least one firewall over a network using a search algorithm; store the firewall rule in a rule database remote from the firewall; classify the firewall rule based on a direction of traffic; and certify the firewall rule based on the direction of traffic.

As used herein, the terms “component” and “system,” as well as various forms thereof (e.g., components, systems, sub-systems . . . ) are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an instance, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

The conjunction “or” as used in this description and appended claims is intended to mean an inclusive “or” rather than an exclusive “or,” unless otherwise specified or clear from context. In other words, “‘X’ or ‘Y’” is intended to mean any inclusive permutations of “X” and “Y.” For example, if “‘A’ employs ‘X,’” “‘A employs ‘Y,’” or “‘A’ employs both ‘X’ and ‘Y,’” then “‘A’ employs ‘X’ or ‘Y’” is satisfied under any of the foregoing instances.

Furthermore, to the extent that the terms “includes,” “contains,” “has,” “having” or variations in form thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.

To provide a context for the disclosed subject matter,FIG. 10as well as the following discussion are intended to provide a brief, general description of a suitable environment in which various aspects of the disclosed subject matter can be implemented. The suitable environment, however, is solely an example and is not intended to suggest any limitation as to scope of use or functionality.

While the above disclosed system and methods can be described in the general context of computer-executable instructions of a program that runs on one or more computers, those skilled in the art will recognize that aspects can also be implemented in combination with other program modules or the like. Generally, program modules include routines, programs, components, data structures, among other things that perform particular tasks and/or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the above systems and methods can be practiced with various computer system configurations, including single-processor, multi-processor or multi-core processor computer systems, mini-computing devices, server computers, as well as personal computers, hand-held computing devices (e.g., personal digital assistant (PDA), smart phone, tablet, watch . . . ), microprocessor-based or programmable consumer or industrial electronics, and the like. Aspects can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects, of the disclosed subject matter can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in one or both of local and remote memory devices.

With reference toFIG. 10, illustrated is an example computing device1000(e.g., desktop, laptop, tablet, watch, server, hand-held, programmable consumer or industrial electronics, set-top box, game system, compute node . . . ). The computing device1000includes one or more processor(s)1010, memory1020, system bus1030, storage device(s)1040, input device(s)1050, output device(s)1060, and communications connection(s)1070. The system bus1030communicatively couples at least the above system constituents. However, the computing device1000, in its simplest form, can include one or more processors1010coupled to memory1020, wherein the one or more processors1010execute various computer executable actions, instructions, and or components stored in the memory1020.

The computing device1000can include or otherwise interact with a variety of computer-readable media to facilitate control of the computing device to implement one or more aspects of the disclosed subject matter. The computer-readable media can be any available media that accessible to the computing device1000and includes volatile and nonvolatile media, and removable and non-removable media. Computer-readable media can comprise two distinct and mutually exclusive types, namely storage media and communication media.

Storage media includes volatile and nonvolatile, removable, and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Storage media includes storage devices such as memory devices (e.g., random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM) . . . ), magnetic storage devices (e.g., hard disk, floppy disk, cassettes, tape . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), and solid state devices (e.g., solid state drive (SSD), flash memory drive (e.g., card, stick, key drive . . . ) . . . ), or any other like mediums that store, as opposed to transmit or communicate, the desired information accessible by the computing device1000. Accordingly, storage media excludes modulated data signals as well as that described with respect to communication media.

The memory1020and storage device(s)1040are examples of computer-readable storage media. Depending on the configuration and type of computing device, the memory1020may be volatile (e.g., random access memory (RAM)), non-volatile (e.g., read only memory (ROM), flash memory . . . ) or some combination of the two. By way of example, the basic input/output system (BIOS), including basic routines to transfer information between elements within the computing device1000, such as during start-up, can be stored in nonvolatile memory, while volatile memory can act as external cache memory to facilitate processing by the processor(s)1010, among other things.

The storage device(s)1040include removable/non-removable, volatile/non-volatile storage media for storage of vast amounts of data relative to the memory1020. For example, storage device(s)1040include, but are not limited to, one or more devices such as a magnetic or optical disk drive, floppy disk drive, flash memory, solid-state drive, or memory stick.

Memory820and storage device(s)1040can include, or have stored therein, operating system1080, one or more applications1086, one or more program modules1084, and data1082. The operating system1080acts to control and allocate resources of the computing device1000. Applications1086include one or both of system and application software and can exploit management of resources by the operating system1080through program modules1084and data1082stored in the memory1020and/or storage device(s)1040to perform one or more actions. Accordingly, applications1086can turn a general-purpose computer1000into a specialized machine in accordance with the logic provided thereby.

All or portions of the disclosed subject matter can be implemented using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control the computing device1000to realize the disclosed functionality. By way of example and not limitation, all or portions of the management component110can be, or form part of, the application1086, and include one or more modules1084and data1082stored in memory and/or storage device(s)1040whose functionality can be realized when executed by one or more processor(s)1010.

In accordance with one particular embodiment, the processor(s)1010can correspond to a system on a chip (SOC) or like architecture including, or in other words integrating, both hardware and software on a single integrated circuit substrate. Here, the processor(s)1010can include one or more processors as well as memory at least similar to the processor(s)1010and memory1020, among other things. Conventional processors include a minimal amount of hardware and software and rely extensively on external hardware and software. By contrast, an SOC implementation of processor is more powerful, as it embeds hardware and software therein that enable particular functionality with minimal or no reliance on external hardware and software. For example, the management component110and/or functionality associated therewith can be embedded within hardware in a SOC architecture.

The input device(s)1050and output device(s)1060can be communicatively coupled to the computing device1000. By way of example, the input device(s)1050can include a pointing device (e.g., mouse, trackball, stylus, pen, touch pad . . . ), keyboard, joystick, microphone, voice user interface system, camera, motion sensor, and a global positioning satellite (GPS) receiver and transmitter, among other things. The output device(s)1060, by way of example, can correspond to a display device (e.g., liquid crystal display (LCD), light emitting diode (LED), plasma, organic light-emitting diode display (OLED) . . . ), speakers, voice user interface system, printer, and vibration motor, among other things. The input device(s)1050and output device(s)1060can be connected to the computing device1000by way of wired connection (e.g., bus), wireless connection (e.g., Wi-Fi, Bluetooth . . . ), or a combination thereof.

The computing device1000can also include communication connection(s)1070to enable communication with at least a second computing device1002by means of a network1090. The communication connection(s)1070can include wired or wireless communication mechanisms to support network communication. The network1090can correspond to a local area network (LAN) or a wide area network (WAN) such as the Internet. The second computing device1002can be another processor-based device with which the computing device1000can interact. For example, the computing device1000can correspond to a server that executes functionality of management component110, and the second computing device1002can be a user device that communications and interacts with the computing device1000.

What has been described above includes examples of aspects of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the disclosed subject matter are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.