System, method and computer program product for rule based network security policies

[0002] The present invention relates to network security, and more particularly to utilizing rule sets associated with network objects for providing network security.

[0003] One of the most significant parts of any firewall configuration is what actions are permitted or denied. The decision is based on an action's parameters such as connection source and destination IP address and host name, user name or group a user belongs to, etc. The current version of the GAUNTLET firewall, as well as other firewalls, uses some variation of “sequential” evaluation approach. Rules are combined in a table or a tree. For every new connection, the firewall searches rule space to find the rule that matches the connection's parameters.

[0004] The big limitation of this approach is the inability to support multiple group memberships in any meaningful fashion. It also fails to present a coherent view of configuration in case multiple group membership is present. A common example of multiple group membership is where a user belongs to more than one user group.

[0005] With the source based approach, a policy map specifies the IP addresses and the IP ranges that are evaluated sequentially at run time. First, a matching entry is used to retrieve the policy. The policy determines whether the connection should be permitted or denied. For permitted connections each policy contains proxy configuration parameters such as anti-virus on/off, the handoff host address, welcome prompt, etc. IP packet screening exists as an independent facility. The packet-screening rules are evaluated from top to bottom and the first rule that matches is used. The packet screening rules have priority over the policy rules enforced by the proxies.

[0006] The advantages of the traditional approach are described immediately above are:

[0007] This methodology is very simple and is well understood by administrators of the firewall.

[0008] Each policy presents a coherent view of what is permitted or denied for a given source object.

[0009] On the other hand, the existing method has significant flaws:

[0010] Network policies cannot be applied to individual users or user groups.

[0011] Sequential search in a monolithic policy table does not allow policies that reflect a user's membership in multiple user groups.

[0012] Firewall configuration is complicated because packet-screening policies are separated from the proxy policies.

[0013] Other approaches to configuration management also exist in the prior art. Firewalls, such as CHECKPOINT, WINGATE and RAPTOR firewalls use what can be loosely described as the “Decision Tree” based approach. The basic building blocks are logical expressions and actions. Logical expressions are evaluated from top to bottom and the first matching expression becomes the enforced policy. Logical expressions may contain source, destination, user name, user group, protocol, time and any combinations of those. The “Decision Tree” may have a single level as in the CheckPoint firewall (“Decision List”) or multiple levels as in the WinGate firewall.

[0014] The “Decision Tree” approach presents the following advantages:

[0015] The methodology is flexible. For example, a configuration could be built to emphasize destinations rather than the source as main criteria.

[0016] User group based policies are supported.

[0017] The disadvantages of the “Decision Tree” approach are:

[0018] The model does not allow viewing all rules per a given network object.

[0019] Incorrect or incorrectly placed rule can have a negative impact on other rules and in some cases can leave the firewall severely misconfigured.

[0020] Multiple user group membership is limited in its scope and can be made meaningful only by carefully tweaking logical expressions. Adding a user to another group may require adding a new expression to the “Decision Tree” to provide the necessary policy evaluation branch.

[0021] There is thus a need for a new method of rule set creation and evaluation.

[0022] A system, method and computer program product are provided for affording network security features. A plurality of network objects are identified. Rule sets associated with one or more of the identified network objects are retrieved. Each network object can have one or more rule sets associated with it. Each rule set includes a plurality of policy rules that govern actions relating to the identified network objects. Overlapping policy rules of the rule sets are reconciled amongst the network objects. The reconciled rule sets are then executed.

[0023] In one preferred embodiment, each policy rule of the reconciled rule sets includes a rule action. One rule action permits an action relating to the identified network objects. Another rule action denies an action relating to the identified network objects. Yet another rule action conditionally denies an action relating to the identified network objects. Preferably, an action relating to the identified network objects is permitted if no policy rules deny the action, at least one policy rule conditionally denies the action, and at least one policy rule permits the action. As an option, the policy rules denying the action are evaluated first and the policy rules conditionally denying the action are evaluated second. The policy rules permitting the action are evaluated third.

[0024] In another preferred embodiment, an action relating to the identified network objects is denied if none of the policy rules permit the action. Further, an action relating to the identified network objects can be denied if none of the policy rules match a request for the action.

[0025] As an option, the rule sets can be combined into a single rule set during execution of the reconciled rule sets. As another option, duplicate policy rules of the rule sets can be removed. Preferably, a user such as an administrator of the system or network is notified of conflicting policy rules of the rule sets so that appropriate correction can be made. Further, a protocol configuration enforced by a related proxy can be selected from a hierarchal list if an action is permitted by more than one rule.

[0026] In another aspect of a preferred embodiment, a computer program product and a method are provided for establishing network security. A plurality of network objects of a network and a plurality of rule sets are provided. The network objects are associated with the rule sets. The rule sets include a plurality of policy rules that govern actions relating to the identified network objects during operation of the network.

[0027] In one preferred embodiment, a user is allowed to associate the network objects with the rule sets via a graphical user interface. In another preferred embodiment, each policy rule of the reconciled rule sets includes a rule action. One rule action permits an action relating to the identified network objects. Another rule action denies an action relating to the identified network objects. Yet another rule action condition ally denies an action relating to the identified network objects. Preferably, an action relating to the identified network objects is permitted if no policy rules deny the action, at least one policy rule conditionally denies the action, and at least one policy rule permits the action. As an option, an action relating to the identified network objects can be denied if none of the policy rules permit the action.

[0028] FIG. 1 illustrates a network'system in accordance with various embodiments of a preferred embodiment;

[0029] FIG. 2 shows a representative hardware environment on which the various components of FIG. 1 may be implemented;

[0030] FIG. 3 shows a process for providing network security features according, to one preferred embodiment;

[0031] FIG. 4 depicts a process for establishing network security according to a preferred embodiment;

[0032] FIG. 5 illustrates the relationship between the network policy, network objects, rule sets, and rules;

[0033] FIG. 6 illustrates a process of combining multiple rule sets according to one preferred embodiment;

[0034] FIG. 7 depicts an example of a network with associated security policy rules sets;

[0035] FIG. 8 demonstrates the process of inserting a new node in a policy database according to one preferred embodiment;

[0036] FIGS. 9 illustrates a graphical user interface that allows a user to associate network objects with rule sets;

[0037] FIG. 10 illustrates a graphical user interface that allows a user to create associations of rule sets and objects for a particular firewall;

[0038] FIG. 11 depicts a graphical user interface displayed upon selection of a network object on the graphical user interface of FIG. 10;

[0039] FIG. 12 shows a graphical user interface displayed upon selection of the rules tab of FIG. 11;

[0040] FIG. 13 illustrates a graphical user interface for creating and editing rule sets;

[0041] FIG. 14 illustrates a graphical user interface for configuring a new rule being added to a rule set;

[0042] FIG. 15 illustrates a graphical user interface for configuring a new rule to a rule set;

[0043] FIG. 16 illustrates a graphical user interface for configuring a new rule to a rule set;

[0044] FIG. 17 illustrates a graphical user interface for configuring a new rule to a rule set;

[0045] FIG. 18 illustrates a graphical user interface for configuring a new rule to a rule set;

[0046] FIG. 19 illustrates a graphical user interface for adding a network object;

[0047] FIG. 20 illustrates a graphical user interface for adding a network object;

[0048] FIG. 21 illustrates a graphical user interface for editing a network object;

[0049] FIG. 22 illustrates a graphical user interface for editing a network object; and

[0050] FIG. 23 illustrates a graphical user interface for editing a network object.

[0051] FIG. 1 illustrates a network system 100 in which a preferred embodiment can be implemented. As shown in FIG. 1, several user terminals 102 are connected to a central server 104. Other network objects such as a printer 106 can also be connected to the server 104. A firewall 108 provides network security.

[0052] A representative hardware environment on which the network server and/or terminals of FIG. 1 may be implemented is depicted in FIG. 2. Such figure illustrates a typical hardware configuration of a workstation in accordance with a prefected embodiment having a central processing unit 210, such as a microprocessor, and a number of other units interconnected via a system bus 212. The workstation shown in FIG. 2 includes a Random Access Memory (RAM) 214, Read Only Memory (ROM) 216, an I/O adapter 218 for connecting peripheral devices such as disk storage units 220 to the bus 212, a user interface adapter 222 for connecting a keyboard 224, a mouse 226, a speaker 228, a microphone 232, and/or other user interface devices such as a touch screen (not shown) to the bus 212, communication adapter 234 for connecting the workstation to a communication network 235 (e.g., a data processing network) and a display adapter 236 for connecting the bus 212 to a display device 238.

[0053] The workstation may have resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. It will be appreciated that a preferred embodiment may also be implemented on platforms and operating systems other than those mentioned. A preferred embodiment may be written using JAVA, C, and/or C++ language, or other programming languages, along with an object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications.

[0054] A broad aspect of a preferred embodiment provides a new way of rule set creation and evaluation. Accordingly, rule sets and objects are viewed as unordered collections rather than traditional tables or trees. Administrator can assign rule sets to network objects. At run time the firewall will try to find every network object that can represent connection and will retrieve and evaluate every rule set for all applicable network objects in order to come up with an answer.

[0055] The approach to firewall configuration according to the various preferred embodiments described herein preferably allows:

[0056] creation of meaningful and reusable rule sets that specify the access rights

[0057] representation of Network Objects as an unordered set rather than an ordered list or a tree

[0058] the ability to merge multiple rule sets with the result consistent with the Administrator's expectations

[0059] the ability to make policy changes without unexpected side effects caused by ordered evaluation

[0060] the ability to fine tune access rights for subsets of the larger Network Objects by specifying additional rules valid for the subset only

[0061] the ability to support backward compatibility with the existing GAUNTLET Firewall configurations.

[0062] FIG. 3 is a flowchart of a process 300 for providing network security features according to one preferred embodiment. In operation 302, a plurality of network objects are identified. Rule sets associated with one or more of the identified network objects are retrieved in operation 304. Each network object can have one or more rule sets associated with it. Each rule set includes a plurality of policy rules that govern actions relating to the identified network objects. In operation 306, overlapping policy rules of the rule sets are reconciled amongst the network objects. The reconciled rule sets are executed in operation 308.

[0063] In one preferred embodiment, each policy rule of the reconciled rule sets includes a rule action. One rule action permits an action relating to the identified network objects. Another rule action denies an action relating to the identified network objects. Yet another rule action conditionally denies an action relating to the identified network objects. It should be noted that such an action includes accessing the associated network object.

[0064] With continued reference to FIG. 3, the rules are analyzed in operations 310, 314, and 316. In operation 310, a determination is made as to whether any of the rules deny the action. If any of the rules deny the action, the action is denied in operation 312. In operation 314, it is determined whether any of the rules conditionally deny the action, upon which a determination is made in operation 316 as to whether any of the rules permit the action. If no rule permits the action, the action is denied. If one rule permits action, the action is permitted in operation 318.

[0065] In the preferred embodiment, the policy rules denying the action are evaluated first (operation 310) and the policy rules conditionally denying the action are evaluated second (operation 314). The policy rules permitting the action are evaluated third (operation 316).

[0066] As shown, an action relating to the identified network objects is permitted if no policy rules deny the action, at least one policy rule conditionally denies the action, and at least one policy rule permits the action. The action is denied if none of the policy rules permit the actions relating to the identified network objects. The action can also be denied if there are no policy rules that match a request for the actions relating to the identified network objects.

[0067] As an option, the rule sets can be combined into a single rule set during execution of the reconciled rule sets. As another option, duplicate policy rules of the rule sets can be removed. Preferably, a user such as a system or network administrator is notified of conflicting policy rules of the rule sets so that appropriate correction can be made. Further, a protocol configuration enforced by a related proxy can be selected from a hierarchal list if an action is permitted by more than one rule.

[0068] FIG. 4 depicts a process 400 for establishing network security. In operation 402, a plurality of network objects of a network and a plurality of rule sets are provided. The network objects are associated with the rule sets in operation 404. A user can be allowed to associate the network objects with the rule sets via a graphical user interface, as described below in the section entitled User Interface for Network Security Configuration, or the associations can be generated automatically according to predefined parameters. The rule sets include a plurality of policy rules that govern actions relating to the identified network objects during operation of the network.

[0069] Again, each policy rule of the reconciled rule sets can include a rule action. One rule action permits an action relating to the identified network objects. Another rule action denies an action relating to the identified network objects. Yet another rule action conditionally denies an action relating to the identified network objects.

[0070] With continued reference to FIG. 4, the rules are analyzed in operations 406, 410, and 412. In operation 406, a determination is made as to whether any of the rules deny the action. If any of the rules deny the action, the action is denied in operation 408. In operation 410, it is determined whether any of the rules conditionally deny the action, upon which a determination is made in operation 412 as to whether any of the rules permit the action. If no rule permits the action, the action is denied. If one rule permits action, the action is permitted in operation 414.

[0071] Preferably, an action relating to the identified network objects is permitted if no policy rules deny the action, at least one policy rule conditionally denies the action, and at least one policy rule permits the action. As an option, an action relating to the identified network objects can be denied if none of the policy rules permit the actions.

[0072] The various preferred embodiments are ideally implemented utilizing the GAUNTLET Firewall security program manufactured by PGP Security, a subsidiary company of Network Associates, Inc. located at 3965 Freedom Circle, Santa Clara, Calif. 95054.

[0073] Network Security Policy

[0074] A network security policy is a collection of rules for allowing and disallowing a specific type of the network traffic by the network objects under specific conditions. A network security policy is established by applying a set of rules to the network topology. The network is presumed to be comprised of the network objects. For the purposes of the network policy a network object is defined as any identifiable network entity such as:

[0075] network objects: an IP address, a subnet, an IP address range

[0076] Authenticated network objects: a user whose location on the network could be determined, a user group

[0077] Any combination of the above objects associated using the logical OR and the logical AND operations

[0078] The Firewall object. See the section below entitled Matching Communications Request with the Rules for a description of this network object

[0079] Firewall Interfaces. See the section below entitled Matching Communications Request with the Rules for a description of these network objects

[0080] “Other” network object. See the section below entitled The Default Network Topology for a description of this network object

[0081] and collections thereof.

[0082] The purpose of a network security policy is to protect the enterprise informational resources based on the proper computer and network use. The local network policy is developed by a network administrator and covers all types of the network traffic for each network object at the enterprise under all operational conditions.

[0083] Policy Components

[0084] The network security policy is expressed using the policy rules or simply rules. Each rule is a predicate that answers a simple question: “Is network object O accessible using network protocol P at this time?”

[0085] Each network policy rule statement is preferably comprised of a network destination object or objects, one or more communications protocols used to access the network object, validity time interval (i.e., the time period for which the rule is valid), a command statement (“permit,” “deny,” “conditional deny”) stating the action taken if the source network object requests access to the network destination object using the communications protocol, and/or the protocol configuration if the destination could be accessed using this network protocol (if the rule permits the access).

[0086] The rules are combined in the rule sets. The rule sets are associated with the network objects to construct a network security policy.

[0087] For example, a rule statement that prohibits access to all destinations in domains d1.com and d2.com is written as:

[0088] dest=*.d1.com, *.d2.com; prot=*; deny

[0089] A formal definition of a policy rule is (in augmented BNF):

[0090] The relationship between the network policy, network objects, rule sets, and rules are presented on FIG. 5. As shown, the network policy elements include a policy 502, a network object 504, a rule set 506, and a rule 510.

[0091] Rule Action Verbs

[0092] Network policy rules may contain the following action verbs:

[0093] Permit

[0094] a rule containing this action verb permits access under certain operational conditions

[0095] Deny

[0096] a rule containing this action verb denies access under all operational conditions

[0097] ?deny

[0098] a rule containing this action verb denies access under certain operational conditions

[0099] In a standalone rule set the “deny” and the “?deny” actions are equivalent and mean that the action is denied. The difference between these two action verbs is notable when the decision has to be made based on two or more rule sets. For more information see the section entitled Competing Policy for Multi-Valued Sources.

[0100] Evaluating Rules in a Rule Set

[0101] For the configuration approach described here, the Windows NT access control list can be used: the rules in a rule set are evaluated using Windows NT access control algorithms. The adoption of the Windows NT approach makes it easier for the Administrator who is already trained to manage Windows domain resources to learn how to configure the GAUNTLET firewall.

[0102] The rules in the rule set are evaluated sequentially using the “first fit” principle starting with the rules containing the “deny” action followed by the rules containing the conditional “?deny” action verb. The rules containing the “permit” action are evaluated next. If none of the rules in the rule set matches the request then the implicit “deny other” rule is applied.

[0103] For the rules with destinations presented as the numeric IP addresses or ranges of the numeric IP addresses a different evaluation criterion is applied. First, the “permit” rule set is searched for a rule that has a network object with the exact IP address as its destination. If such rule is present, then the protocol configuration specified with this rule is used by the proxy for this connection. If the rule with the exact matching destination IP address is not found, then a list of all proxy configurations associated with the rules that include the destination IP address, except the ‘*’ destination, is built. If no matching IP ranges are found, the protocol configuration associated with the ‘*’ destination is used.

[0104] For named destinations the matching FQDN (Fully Qualified Domain Name, RFC 2109) is equivalent to IP address, the domain names containing the wild card symbol “*” are equivalent to IP ranges. This is an advanced feature that requires reverse DNS lookup.

[0105] If more than one protocol configuration is selected, the result is chosen from the list of the selected protocol configurations according to the selection order established by the Administrator. See the section entitled Resolving Network Protocol Configuration for more information on the protocol configuration selection. The Administrator does not need to sort rules in a proper order when she creates a rule set. The rules are rearranged automatically when the network policy is compiled. This feature applies also to the case when more than one rule set is combined when associated with a single network object.

[0106] The ability to define the network topology and rule sets independently of each other is a significant advantage of the preferred embodiment FIG. 6 illustrates an exemplary process 600 of combining multiple rule sets. In this example, the Administrator defines rule sets 602, 604 for the http and the ftp protocol separately and applies both rule sets to one network object 606. The resulting rule set 608 is computed as a superposition of the applied rule sets. Note that the “deny” rules are moved to the top of the combined rule set according to the rule set evaluation order.

[0107] When a new aggregate rule set is created, all duplicate rules are merged in a single rule. Rules that match exactly except the action verb are contradictory and cannot be merged in an aggregate rule set. The Policy Builder should bring this matter to the Administrator's attention and refuse to create a contradictory rule set. For example, the following two rules are contradictory:

[0108] d=A.com; p=smtp; permit

[0109] d=A.com; p=smtp; deny

[0110] and cannot be merged in a single rule set.

[0111] Another possible approach to specifying the rule set is to ask the Administrator to sort the “permit” rules in the desired fashion. This approach disallows applying more that one rule set to a network object.

[0112] Associating Rule Sets with the Network Objects

[0113] Each network could be presented as a collection of the network objects. In order to create a network policy the Administrator associates one or more rule sets with some of the network objects present on the network. The rules contained in the rule set define the network object's access rights to other network objects. The default rule “deny all” is applied to the network objects for which network policy rules sets were not applied explicitly.

[0114] An example of a network 700 with associated security policy rules sets are presented on FIG. 7. The network is physically comprised of the three subnets denoted as S1702, S2704, and S3 (not shown). There are two user groups defined called “Executives” and “Accounting” and denoted E and A respectively. One may assume that only Executives have access to the computers on the S1 subnet.

[0115] The Administrator creates three rule sets:

[0116] The Administrator created the following three network objects for which the network security policy is enforced and applied to them the above rule sets RS1706, RS2708, and RS3710:

[0117] RS1 & RS2 & RS3→S3|A:

[0118] By applying rule set RS3 and rule set RS2 to object S3 the Administrator prohibits access to the destinations in the C.com and B.com domains for all http connections that are initiated from the S3 subnet or by any user in the Accounting group no matter from which host he starts the communications session.

[0119] RS1 & RS2→S2|E:

[0120] Rule set RS2 prohibits all users which do not belong to the Accounting or the Executive group from accessing destinations at the B.com domain using the http protocol. The Administrator prohibits the Executives working from the machines in the S2 domain from accessing that site as well so that other employees cannot oversee the information viewed by the Executives.

[0121] RS1→S1 & E:

[0122] The S1 subnet is used exclusively by the Executives working from their private computers. Even if any other employee outside of the Executives group gains physical access to a computer on the S1 subnet, she cannot access the sites at the B.com domain.

[0123] When the rule set is applied to a network object the rule statements in the rule set are ordered according to the rule set evaluation algorithm.

[0124] Computing Policy for Multi-Valued Sources

[0125] Managing network objects that span multiple network object groups is a challenging task. Traditional policy management methods avoid dealing with this problem. The task of computing the policy rule for a multi-valued source arises when, for example, the user belongs to more than one user group. For example, Bob is a Manager in the Engineering department. If the Managers have a set of privileges different from that of the Engineers, then what of the two rule sets define the policy applied to the Bob's request? See the section entitled Matching Communication Request with the Rules below for a complete list of multi-valued sources.

[0126] If the policy rule is computed from more than one rule set then a two step evaluation process is applied. Initially, the applicable policy rule is selected from each rule set under consideration. The rule is selected using the rule selection procedure described in the section entitled Evaluating Rules in a Rule Set above. The computation in each rule set yields a rule with one of the action verbs defined in the section entitled Rule Action Verbs above. In addition, some of the rule sets may contain no matching rule for the given request and yield the implicit “deny all” rule located past the last “permit” rule in the rule set. For computing the final rule, the implicit “deny all” action is interpreted as the decision delegation to other rule sets under consideration.

[0127] After each individual rule set yielded an appropriate rule, the policy rule is selected using operational table presented below. In Table 1, P denotes rule sets that yielded a rule containing the “permit” verb, D denotes rule sets containing the “deny” verb, d denotes rule sets containing the “?deny” (conditional deny) verb, Ø denotes rule sets that yielded the implicit “deny all” rule.

[0128] The selection process of the policy rule could be expressed verbally as:

[0129] The access is permitted if none of the rule sets yielded an explicit denial and one or more of the yielded rules contain permission. The access is denied otherwise.

[0130] The following example demonstrates the policy computation. Bob is a manager in the Engineering department and is placed by the Administrator in both the Managers and the Engineers user groups. The Managers group has the following rule set associated with it:

[0131] The Engineering group is governed by the following policy rule set:

[0132] When Bob accesses a Web site in the A.com domain rule set RS_Myields rule M1 and rule set RS_Eyields rule E1 that contains the “deny” action and Bob's request is denied.

[0133] If the Administrator rewrite the E rule set as:

[0134] replacing the explicit “deny” action with the conditional “?deny” action, then Bob's connection is established because rule E1 with the conditional “?deny” action is overridden by rule M1 containing the “permit” action. On the other hand Bob's request to establish ftp connections are still denied according to rules M2 and E3.

[0135] As a member of the Managers group Bob also can send e-mail messages since rule set E does not contain any rule for regarding the smtp protocol. The members of the Engineers group are denied access to e-mail since rule set E implicitly denies smtp requests.

[0136] Access is permitted only when there is an explicit permit rule and there is no explicit deny rule. Action word “deny”, introduced in a previous section, creates an explicit deny rule. Action words “permit” and “?deny” together define explicit permit rules where “?deny” is limiting the scope of “permit” rule that follows.

[0137] To illustrate the difference between denied actions and not-permitted actions, another hypothetical case is set forth. Engineers have access to some super-secret information and because of that should not be able to access e-mail to prevent them from accidentally or on purpose disclosing this information to someone else. Managers have access to personal files and can use e-mail. Engineers are not permitted access to personal files. Managers have no access to secret information. As expressed in rule sets:

[0138] Engineers→RS1

[0139] Managers→RS2

[0140] There is no need to deny access to secret information for Managers and to personal information to Engineers because it is not permitted and as such is implicitly denied. Now, what happens to an Engineering Manager? He gets access to both secret information and personal information, however, access to secret information implies no e-mail access and that is achieved by explicitly denying e-mail access to the Engineers.

[0141] Matching Communications Request with the Rules

[0142] In order to determine the policy, data in the communications request is matched to one or more network objects. The rule sets associated with the selected network objects yield a decision if the connection should be permitted or denied and what configuration should be used if the connection is permitted.

[0143] The incoming communications request contains the following parameters on which the policy decision is made:

[0144] 1. source IP address

[0145] 2. source user name and user groups to which the user belongs

[0146] 3. destination IP address

[0147] 4. network protocol

[0148] Data items (1), (3), and (4) are immediately available when a regular TCP connection is being established. The value in the field (2) is derived from the user name or the user id. The user name (id) is available for the network protocols supporting user authentication (http, ftp, SMB) and for the users of the GAUNTLET Single Sign-On (SSO) facility.

[0149] The proposed model suggests the mechanism of the explicit network objects to allow the Administrator to quickly amend the existing network policy. When creating a network object the Administrator may wish to designate a network object as explicit. Rule sets associated with the explicit network objects that reference the network object contained in the request are evaluated first. This feature allows the Administrator a fine grain of immediate control over the existing network policy.

[0150] In order to make a policy decision regarding the communications request, a collection of rule sets that influence the outcome is assembled.

[0151] For each incoming connection the following happens:

[0152] 1. Select all explicit network objects with associated rule sets that match connection request;

[0153] 2. If some are selected stop the search and go to step 6;

[0154] 3. Continue the search in the remaining network objects with associated rule sets;

[0155] 4. If some are selected stop the search and go to step 6;

[0156] 5. Select the “Other” object with its rule set;

[0157] 6. Select relevant interface network object with its rule set;

[0158] 7. Add the rule set for the firewall network object;

[0159] After the applicable rule sets are selected, the decision is made according to the algorithm described above in the section entitled Computing Policy for Multi-Valued Sources.

[0160] The Policy Database Structure

[0161] A record in the Policy Database consists of a 4-tuple, an action, and a network protocol configuration object if the action value is “permit”:

[0162] db-src-addr-value

[0163] db-src-user-group-name

[0164] dest-value

[0165] prot-name

[0166] action [prot-config-object]

[0167] The Policy Database is organized in a structure known as the k-d tree. The k-d tree is a specialized structure designed for storing multi-valued objects such as vectors. Insertion of a new element in the k-d tree is done by evaluating each subsequent vector coordinate against the corresponding coordinate of the current tree node. FIG. 8 demonstrates the process 800 of inserting a new node in a k-d tree of a two dimensional vector (x, y), x, y ε R. At the root node the first coordinate, x, is compared with the value of the first coordinate in the node, x1, and the traversal direction is selected depending on the outcome of this comparison. If x<x1, then the next evaluated node is (x2, y2). Here the second vector coordinate, y, is compared with the second coordinate of the node, y2. If y>y2, the next evaluated node becomes node (x3, y3). The first coordinate, x, is compared now with the first coordinate of this node, x3. If x>x3, then vector (x, y) is inserted as the right child of the leaf node (x3, y3).

[0168] The Policy Database k-d tree is built only once when the user-friendly representation of the network security policy is compiled. At the run time the search for the matching object in the Policy Database could be minimized by balancing the tree structure.

[0169] Resolving Network Protocol Configuration

[0170] Network protocol configuration is an important part of the rule. Network protocol configuration defines the constraints on the requestor's ability to perform the actions allowed by a network protocol. Network protocol configuration is enforced by the respective proxy agent. For example, the http proxy could be configured either to perform or not to perform anti-virus scanning of the retrieved data for a particular request depending on the http protocol configuration associated with the request.

[0171] The problem of selecting a protocol configuration arises when a communications request is granted by two or more “permit” rules statements at the same time. This may happen, for example, if the requestor belongs to two or more user groups, each of which is allowed to access a certain network object but under different constraints specified by the network protocol configuration. The same problem may be solved when the source IP address of the connection belongs to the intersection of two or more IP address ranges.

[0172] The resolution of the protocol configuration collision is done through a hierarchy of the preferred network protocol configurations created by the Administrator. When specifying the protocol configurations, the Administrator creates an ordered list of those. At the run-time a network protocol configuration with the highest priority assigned by the Administrator is selected from the list of the protocol configurations in the result rule set.

[0173] This approach to selecting the network protocol configuration allows selecting a proper configuration using a set of statically defined objects—a measure that speeds up the process of the decision making.

[0174] A combination protocol configuration can be computed by combining settings from all configurations. In order to provide the ability to compute a combination configuration each network protocol configuration item is associated with a respective object that defines the configuration item setting restriction level. The presence of the constraints metering object allows to compare two generic configuration settings and to select the least restrictive option setting. When queried, the constraints metering object returns an integer value in the range between 0 and N. The value of 0 corresponds to the least restrictive setting and the value of N denotes the most restrictive setting of the configuration parameter. For example, in case of the virus scanning, the query on this configuration parameter for the constraints metering returns 0 for the configuration where virus scanning is not required and the value of 1 for the configuration setting that requires virus scanning. The range of the returned values could be arbitrary long for multi-valued configuration parameters. The restriction neutral configuration parameter constraints metering object returns same value independent of the actual parameter setting.

[0175] The dynamic approach that combines statically defined network protocol configurations requires more computational power but, on the other hand, allows creating highly flexible policies and solves the problem of the configuration ordering for the Administrator.

[0176] The Default Network Topology

[0177] The default network topology forms the basis of any network policy. The following network objects constitute the default topology:

[0178] The Firewall object

[0179] The Firewall Interfaces

[0180] The “Other” network object

[0181] The Firewall object and the interface objects are evaluated for all requests that traverse the Firewall. The “Other” object represents all network objects that the Administrator did not introduce individually or as an element of other network objects. A rule set associated with the “Other” network object governs these objects behavior.

[0182] Impact on the Existing Proxy and Driver Implementation

[0183] The proposed approach has little impact on proxies. Only implementation of the API used to retrieve proxy configuration has to change. There are three options/stages how the GAUNTLET driver is introduced to the new configuration management style:

[0184] a. No change initially. Packet screening rules are not a part of the rule sets.

[0185] b. Rule sets containing packet-screening rules are not applied to the user group network objects. The driver adopts the new way of rule set evaluation but uses only IP network objects.

[0186] c. The proposed network management model is fully supported by the driver.

[0187] Following is a definition of proxy configurations that will be used throughout the examples.

[0188] HTTP

[0189] HTTP1 (allow everything)

[0190] HTTP2 (allow everything anti-virus on)

[0191] HTTP3 (deny Java & ActiveX)

[0192] HTTP4 (use handoff to inside web server)

[0193] FTP

[0194] FTP1 (allow everything)

[0195] FTP2 (use handoff to inside server)

[0196] Other proxies will follow this scheme.

[0197] A Simple Configuration

[0198] Inside subnet, connected to firewall interface IF1, is allowed to go out with a number of protocols, outside access, on IF2, is allowed to inside FTP and Web server through handoff.

[0199] The rule sets for this configuration:

[0200] Create the inside network object

[0201] NO1←RS1

[0202] “Others”←RS2

[0203] or

[0204] IF1←RS1

[0205] IF2←RS2

[0206] In Addition to Example 1 Some Inside Machines Need Access to SQL and Port 1111/TCP

[0207] NO1←RS1

[0208] “Other”←RS2

[0209] NO2←RS3

[0210] For connections originated from one of NO2 IP addresses RS1 and RS3 are applied, for other inside connection only RS1 is used as before. Note, that one does not need to find any particular spot for NO2, nor does one have to duplicate RS1 in RS3.

[0211] Same as Example 2 But Additional Access is Granted to Members of User Group 1 (UG1)

[0212] NO1←RS1

[0213] “Other”←RS2

[0214] UG1←RS3

[0215] Explicit Deny Rule

[0216] UG1←RS1

[0217] UG2←RS2

[0218] User1←UG1 permitted HTTP

[0219] User2←UG2 denied HTTP

[0220] User3←UG1+UG2 denied HTTP

[0221] Because HTTP is explicitly denied in RS2 it means “deny HTFP access to any member of this group even if other groups he belongs to allow HTP”. If deny rule is removed from RS2 then the result is

[0222] User1←UG1 permitted HTTP

[0223] User2←UG2 denied HTTP (no permit rule is found)

[0224] User3←UG1+UG2 permitted HTTP (does not have explicit deny rule anymore, has permit rule)

[0225] Conditional vs. The Explicit Deny Rule

[0226] UG1←RS1

[0227] UG2←RS2

[0228] User1←UG1 permitted HTTP anywhere except *.website.com

[0229] User2←UG2 permitted HTTP anywhere

[0230] User3←UG1+UG2 permitted HTTP anywhere

[0231] Because conditional deny is used in RS1 the meaning of RS1 can be expressed as “permit HTTP to any destination except *.website.com”. If conditional deny is replaced with explicit deny the result changes to:

[0232] User1←UG1 permitted HTTP anywhere except *.website.com

[0233] User2←UG2 permitted HTTP anywhere

[0234] User3←UG1+UG2 permitted HITP anywhere except *.website.com

[0235] Conflicting “Permit” Statements

[0236] UG1←RS1

[0237] UG2←RS2

[0238] User1←UG1 permitted HTTP with configuration HTTP2

[0239] User2←UG2 permitted HTTP with configuration HTTP3

[0240] User3←UG1+UG2 with configuration HTTP2, because it has a higher preference set by the Administrator

[0241] IP Network Objects and SSO Authentication

[0242] Each IP network object should have authentication attribute set by the Administrator. It should be possible to set authentication to:

[0243] allow SSO authentication;

[0244] prohibit SSO authentication (a subnet if Unix workstations);

[0245] User Interface for Network Security Configuration

[0246] FIGS. 9-23 illustrate graphical user interfaces (GUIs) that allow a user such as an Administrator to associate network objects with rule sets across an enterprise. For example, see the discussion with reference to FIG. 4, above, for a description of a process for establishing network security that can be performed with the graphical user interfaces described herein. As shown on the screen 900 of FIG. 9, various location icons 902 of an enterprise are shown. The user is allowed to select a particular location icon to display security features, such as firewall icons 904 and rule set icons 906, of that location. Because each rule set is a shared resource, each location can have several firewalls that each use the rules from the rule sets. On this screen, the user is allowed to create new rule sets for an entire location and modify existing rule sets. By right clicking on a particular icon, for example, a menu is displayed that allows the user to create, edit and/or delete the objects, items or rules represented by the icon.

[0247] FIG. 10 illustrates a screen 1000 that allows a user to create associations of rule sets and objects. As shown, the user selects a particular firewall icon and icons 1002 representing network objects or groups of network objects are displayed. Each icon representing a group of objects should be denoted in some manner. Here, such icons representing a group of objects are denoted by a check mark. Again, right clicking on an object icon displays a menu 1004.

[0248] FIG. 11 depicts a screen 1100 displayed upon selection of a network object, such as by selecting the “Properties” or “Edit” item of a menu of the icon representing the network object. See FIG. 10. The screen displays the object or objects represented by the object icon. Upon selection of the OK button 1104, changes are saved. Selecting the Cancel button 1106 exits the screen without saving changes. It should be noted that selection of the OK and Cancel buttons on other screens shown in Figures herein operate in a similar manner. FIG. 12 shows a screen 1200 displayed upon selection of the rules tab 1102 of FIG. 11. From here, rules relating to the particular object(s) can be edited.

[0249] FIG. 13 illustrates a screen 1300 for creating and editing rule sets. As shown, the destination, time limits, protocol (port), facility, configuration, and rule action of each rule in the rule set are displayed. The action of a particular rule can be represented by an icon. Here, a stop icon 1302 represents a deny action. An icon 1304 with a question mark represents a conditional deny action. A smiling icon 1306 represents a permit action. By selecting the New button 1308, the user can add new rules. Upon selecting a rule, such as by clicking on a line, and pressing the edit button 1310, the user is allowed to edit the parameters of the rule.

[0250] FIG. 14 illustrates a screen 1400 for configuring a new rule when adding a new rule to a rule set. Such screen is displayed upon selection of the New button of FIG. 13 or the New Rule icon of FIGS. 9 and 10. The user can select a destination from the icon box 1402 or can enter one in the destination entry field 1404. The user then selects the Next button 1406. The user then selects the time and days of the week that the rule is in effect (or not in effect) on the screen 1500 of FIG. 15 and selects the Next button 1502. The screen 1600 of FIG. 16 is displayed. Here, the user selects the mechanism that enforces the rule from the facility field 1602, enters the port number (optionally) and selects the transport protocol. The user then selects the Next button.

[0251] FIG. 17 depicts a screen 1700 that allows selection of an action for the rule. Upon selection of the desired rule action, the Next button is selected. The user is allowed to select a protocol configuration on the screen 1800 shown in FIG. 18. Upon making the selection, the user selects the Finish button 1802 and the rule is added to the rule set or the edits are made to the rule.

[0252] FIGS. 19 and 20 illustrate screens for adding a network object. FIG. 19 illustrates a screen 1900 for selecting a type of the network object. The object type is selected and the Next button is selected to display the user group screen 2000, shown in FIG. 20. Upon selection of the user group, the Finish button is selected to save the network object.

[0253] FIGS. 21-23 illustrate screens for editing a network object. The screen 2100 of FIG. 21 displays the selected network object. FIG. 22 depicts a screen 2200 that allows selection of the other network object(s) that will be associated with the object shown in FIG. 21. FIG. 23 illustrates a screen 2300 that allows creation of the relationship between the selected network objects, here an and/or relationship.

[0254] Accordingly, the present network policy management model combines the familiar rule-based policy specification with the advanced network topology based policy representation. Simple policy rules syntax and semantics hide the complexity of the policy specification from the Administrator by aggregating policy fragments in a complete network policy. Thus, the rule-based models achieve the following objectives:

[0255] policy rule specification is separated from the network objects specification allowing a modular way of creating network policies

[0256] policy rule sets could be unambiguously merged allowing a smaller and more manageable set of the basic policies

[0257] allows for a simple “drag-and-drop” user interface

[0258] supports defining policies based on the source user name and IP addresses, destination IP addresses or DNS names, and the network protocols

[0259] supports the notion of the intersecting network objects (e.g. a user belongs to more than one user group) and allows determination of a policy for the elements in the intersecting subset

[0260] allows easy policy amendment for a single object (user, IP address) which previously had no policy of its own

[0261] allows imposition of a global mode of the firewall operation in a single step by supporting the global source network object.

[0262] While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.