Patent Grant
7478422
1. Technical Field
The invention relates to security and network services. More particularly, the invention relates to a declarative language system used in defining policy for an entire network and in providing monitoring and enforcing of computer network security.
2. Description of the Prior Art
Security administrators need tools that help them formulate their site security policy and translate it into monitoring and enforcement mechanisms. They need to be sure that the computer enforced policy—often cobbled together from a plethora of disjoint access control mechanisms—matches their enterprise policy, all too often specified in a loose natural language or a set of unwritten principles. This leads to confusion as to why access is being granted or denied to particular resources and may lead to unintentional breaches of security.
A way to reduce or eliminate the confusion described above is by providing a user-friendly and, yet, rigorous way of specifying security policy, as well as providing tools for monitoring and enforcing the security policy.
Blaze, Feigenbaum, and Lacy (BFL), Decentralized Trust Management, Proc. IEEE Conference on Security and Privacy (1996), used the term trust management to refer to a problem of deciding whether requested actions, supported by credentials, conform to policies. In other words, it deals with the questions of who, how, and what. Who (the principals, for example, people, computers and organizations) can access what (the resources being sought) and how (the actions performed against the target resources).
Mansouri-Samani, et al, GEM: A Generalized Monitoring Language for Distributed Systems, Distributed Systems Engineering, vol. 4, no. 2 96-108 (June 1997) discloses a generalized-event monitoring notation that permits user-specified filtering and composition scripts to be dynamically loaded into distributed-event monitoring components. GEM uses “scheduled time events and default or user-defined detection windows” to cope with “variable communication delay problems.” The GEM event monitoring system is used “to detect complex event sequences and to convert these into simple events” that trigger management actions. The event monitors have been restricted to performing “very simple activities related to triggering or notifying events.”
J. A. Grompone, A Declarative Language for the Configuration of Exchanges, Telecommunications Journal, vol. 56, no. 1 (January 1989) discloses the design and implementation of a high-level language, LEP, to define the routing and customizing of rules of a telex exchange. The routing concepts are basic and few in number. Each of the physical communication paths is called a line. The lines are arranged in groups. The purpose of the LEP language is to provide a comprehensive definition of all lines of an exchange, the arrangement of these lines in groups and the physical attributes of the groups. All groups taken together comprise all the lines without any lines missing or being repeated. A group is an ordered set of lines. The LEP term “access” is used to denote whether lines are permitted or forbidden to access other lines or services. Routing, a basic objective of an LEP program, is a way of associating sets of compiled codes with destinations, done through a sequence of elementary declarations. LEP also defines the possible destinations of a call. One of the main design concepts was to use a very simple structure for the declarations for even users unfamiliar with computer programming.
The LEP language cannot thread together multiple protocol layers of a network event. The LEP language lacks the sophistication in terms of richer expressions to allow a set of policy rules affecting different networking protocols to be applied to a complex protocol interaction between two communicating parties, and to security policy for an entire network. The LEP language does not suggest defining allowed traffic patterns and handling those events that deviate from those patterns.
Plasek, et al, Statistical Database Query Using Random Sampling Of Records, U.S. Pat. No. 5,878,426, discloses a method for obtaining decision support query results from a database table having multiple records. An attribute of the database table is sampled, which results in a collection of sampled data. The sampled data represents some percentage of all of the data corresponding to that attribute in the database table. The data associated with the attribute includes multiple data classes, and the sampled data is separated or partitioned into these data classes. A database query is applied to the sampled data rather than to all of the data corresponding to that attribute in the database table.
Plasek, et al, also discloses a method to obtain decision support query results from a database table where all of the data associated with a particular database attribute is grouped into various data classes. Each of the data classes is individually randomly sampled to obtain a corresponding number of class data samples. Each of the class data samples is then queried, which can include executing aggregation functions on each of the class data samples.
Plasek, et al, also discloses a method for providing result approximations in database queries.
Plasek, et al, does not disclose nor suggest providing a method to select a most specific and applicable result or policy rule. Plasek, et al, does not disclose nor suggest providing a method to rank data and does not order data in a database beyond partitioning data into classes and thereafter randomly sampling each data class such that database queries are applied to each of the samples.
Plasek, et al, does not disclose nor suggest providing a method to thread protocol layers of a network event together to provide a result to the network event.
Chow, et al, System, Method, and Program for Extending a SQL Compiler for Handling Control Statements Packaged with SQL Query Statements, U.S. Pat. No. 5,875,334 (Feb. 23, 1999) discloses an integrated compiler for compiling SQL3 control statements having procedural, i.e., control, information packaged together with query, i.e., non-procedural, statements. A query extractor contained within the parser extracts the query statement from the control statement leaving a control skeleton. The query statement is processed as usual through a query compiler for generating executable plans with the exception that the name resolution function for resolving variables is modified for looking up local variables. This modification takes into account the mapping of local and host variables to create a unification of local and host variables. The control skeleton is processed through a control analyzer which generates a representation of the control flow and a scope and symbol table. The control analyzer also unifies the local and host variables. A plan synthesizer then takes as input the control flow information, symbol tables, and individual executable plans for the query statements and generates a meta-plan comprising a merger of a top level plan for the control skeleton and sub-plans representing the executable plans of the query statement.
Chow, et al, does not disclose nor suggest a ranking method or an ordering method to handle a set of rules to be applied to a complex protocol interaction between two communicating parties.
Nor does Chow, et al, disclose or suggest a method whereby to thread protocol layers of a network event together to provide a rule applicable to the network event.
V. Paxson, Bro: A System for Detecting Network Intruders in Real-Time, Network Research Group, Lawrence Berkeley National Laboratory, Berkeley, Calif., LBNL-41197 (January 1998) discloses a stand-alone system for detecting network intruders in real-time by passively monitoring a network link over which the intruder's traffic transits. The system comprises a “policy script interpreter” that interprets event handlers written in a specialized language used to express a site's security policy. The specialized language is C-style because it comprises, for example, C-style data types and constants, operators, and block statements and is procedural. Bro comprises first-class values and aggregate types such as record and table, used to specify a security policy.
However, Paxson does not disclose nor suggest providing a sophisticated ranking method to rank policy rules according to the specificity of the initiator and target communicating hosts and to select a most applicable rule in an efficient manner. Paxson does not disclose nor suggest providing a method to thread protocol layers of a network event together to provide a result to the entire network event.
It would be advantageous to reduce or eliminate the confusion described herein above by providing a user-friendly and, yet, rigorous way of specifying security policy, as well as providing tools for monitoring and enforcing the security policy.
It would be advantageous to have a trust manager that takes as its input a security policy defined as a set of policy rules (statements about trust) and a set of credentials (statements about principals), such that it is capable of processing requests for trust decisions, i.e. evaluating compliance with the policy.
It would be advantageous for the trust manager to have a unified view of an interaction between two principals across a stack of protocol layers, each governed by discreet policy rules, and to apply a final trust decision based on which of these policy rules better fits the entire interaction. For example, using HTTPS to access a secure web page involves an interaction between two network addressable machines (at the TCP/IP level), an interaction between a cryptographically authenticated server and, possibly, a cryptographically authenticated client (at the SSL level), and an interaction between a Web browser (possibly with its own authentication credentials) and a web server, resulting in the retrieval of a web page (at the HTTP level).
It would be advantageous to have a policy definition language as well as well-designed algorithms to support monitoring and auditing network activity, in addition to traditional access/deny authorization decisions. For example, a policy rule might instruct a monitoring Agent to log all traffic between two computers or to decrypt a secure channel between two users.
It would be advantageous to provide a system that comprises a passive monitor of network traffic that does not need to be installed on target hosts or integrated into existing applications.
It would be advantageous to provide a system that uses a sophisticated algorithm for determining which policy rules take precedence over others.
It would be advantageous to provide a policy language that allows a set of policy rules affecting different networking protocols to be applied to a complex protocol interaction between two communicating parties. Also, it would be advantageous to use the policy language to express security policy for an entire network.
It would be advantageous to provide a system, unlike current Intrusion Detection Systems (IDS) which only look for signatures of known attacks, focusing on defining allowed traffic patterns and determining how to handle events that deviate from those patterns.
The invention is a declarative language system and comprises a language as a tool for expressing network security policy in a formalized way. It allows the specification of security policy across a wide variety of networking layers and protocols. Using the language, a security administrator assigns a disposition to each and every network event that can occur in a data communications network. The event's disposition determines whether the event is allowed (i.e. conforms to the specified policy) or disallowed and what action, if any, should be taken by a system monitor in response to that event. Possible actions include, for example, logging the information into a database, notifying a human operator, and disrupting the offending network traffic.
The language is implemented by a Policy Engine, a component also of a Security Policy Monitoring (SPM) system. The SPM system, also referred to herein as the Policy Monitoring System, is ideally suited for network and security assessments where real network traffic is analyzed in order to identify abnormal traffic patterns, system vulnerabilities and incorrect configuration of computer systems on the network.
Unlike other trust management systems, the SPM is designed to be a passive monitor of network traffic. As such, it need not be installed on target hosts or integrated into existing applications.
The invention provides a simple and intuitive model for expressing and applying security policies. The language is much richer in terms of what it can express than languages used in firewalls and routers. It uses a sophisticated algorithm for determining which policy rules take precedence over others, a process that in other systems is completely manual.
Unlike existing firewalls and routers, the invention allows a set of policy rules affecting different networking protocols to be applied as a whole to a complex protocol interaction between two communicating parties. Furthermore, networking equipment typically handles only policy related to the network traffic that flows through it. Using the invention herein one can express the security policy for an entire network.
Unlike IDS systems, which look for the signatures of known attacks, the SPM is focused on defining allowed traffic patterns and how to handle events that deviate from those patterns.
a is a schematic diagram of a network event, comprising protocol events at different protocol layers, having an associated network event disposition according to the invention; and
b is an algorithm showing protocol events at different protocol layers resulting in pending rules with or without immediate outcomes and, finally, a final disposition for the network event.
Overview
In the preferred embodiment the Policy Engine 101 consults a policy information database, a Policy Store 104 to determine a policy rule that applies to the network event 103. In the preferred embodiment the Policy Engine 101 collects input from the Agent 102 about each protocol event until it has enough information to consult the Policy Store 104. Once an applicable policy rule for the entire network event 103 has been found, the Policy Engine 101 returns a disposition 105 for the event to the policy manager module which in turn forwards it to the Agent 102, to a logging subsystem and, optionally, to an enforcement subsystem.
A definition of a protocol event is provided to facilitate understanding of the invention. A protocol event 120 as shown in
1) The Principals. Every policy decision involves two principals: an initiator 121 (an active principal) and a target 122 (a passive principal). Principals are identified by a set of one or more credentials, depending on how much information is known about them and what protocol service they are using. There are three types of credentials:
2) The Protocol. The protocol service 123 associated with this protocol event 120.
3) The Security Quality of Service Parameters. Some protocols include security QOS parameters 124 and these may be subject to local security policy constraints. For example, in the SSL protocol the ciphersuite negotiated between the SSL client and the SSL server is a security QOS parameter.
4) The Action. Every interaction between an initiator and a target over a given protocol service involves a specific action 125. Clearly, not all actions are of interest to the policy manager module. For example, in the SSL protocol only actions pertaining to the establishment or termination of an SSL session, most notably, the negotiation of security parameters for the session are of interest. In the LDAP protocol, on the other hand, a security policy administrator may wish to express policy statements about different LDAP data manipulation operations, such as, the SEARCH and MODIFY operations.
In one embodiment of the invention, while processing a network event 103, and before issuing a final ruling, the Policy Engine 101 may instruct the Agent 102 to carry out specific actions against the network event 103. For example, the Agent 102 may be asked to decrypt subsequent SSL traffic or it may be asked to impose a specific ciphersuite on the target system. These instructions constitute an intermediate output of the Policy Engine 101 and are issued in the form of agent directives, defined herein below.
Once the Policy Engine 101 arrives at a final policy decision, it produces a disposition 105 for the event 103. The disposition 105 as shown in
1) Disposition Code. The disposition code 131 denotes whether or not the event 103 complies with the security policy and, if not, identifies the specific policy violation. A list of possible codes in a preferred embodiment is given in Table A herein below. This field is mandatory.
2) Logging Directives. The logging directives field 132 includes a severity code, denoting the severity of the policy violation. A list of possible severity values in a preferred embodiment is given herein below in Table B. The severity code may be used by a logging subsystem to filter the event 103 and its disposition 105 or to control a notification action, e.g. page a network operator. In another embodiment the logging directives 132 may also include an optional human readable description summarizing the specific policy that determined the final disposition 105 e.g. “blue users cannot access the red server”. The logging directives field 132 is mandatory if the disposition code 131 indicates a policy violation.
3) Agent Directives. Agent directives 102 are any instructions that need to be communicated to the Agent 102 and in another embodiment to more than one Agent. For example, the Agent 133 may be instructed to log all traffic associated with the event 103 or to disrupt communications between the initiator 121 and the target 122. In some embodiments, an Agent 102 only supports monitoring functions, or only enforcement functions, or be limited in its support of other types of functions. In a preferred embodiment, a policy manager is responsible for distributing a set of directives to appropriate Agents.
4) Event Constraints. Event constraints 134 are any constraints to be applied to the event 103. For example, in one embodiment these constraints are protocol-specific constraints such as the maximum lifetime of a TCP connection or the maximum lifetime of an SSL session. In another embodiment, these constraints are communicated to the Agent reporting the event or simply to a policy manager.
Now, the dispositions and policy rules built into the Policy Engine. These rules can be overwritten by user-defined policy rules.
It is noted that the list of built-in objects included in Table A is by no means complete. In other embodiments, the set of built-in objects is expanded or reduced to reflect the set of protocols supported by the Policy Monitoring System.
It is noted that in the preferred embodiment the Policy Engine 101 ranks default-rule lower than any user-defined rule. For example, a user-defined rule having initiator and target credentials set to ignore ranks higher than using default-rule.
In a preferred embodiment, security policy decisions are also affected by any previous history of security violations involving one or both of the principals.
Specification Language
A security policy is formulated using the Policy manager module's policy specification language (
An advantage of using the canonical representation of S-expressions in the preferred embodiment is for digital signature purposes as well as for relatively efficient communication. It is easy to parse, fairly compact, and is unique for any given S-expression. An advantage of using the advanced representation of S-expressions is for human consumption. It can be thought of as a pretty print of the canonical representation.
It should be noted that replacing language tokens (e.g. certificate, issuer) with minimally encoded identifiers further optimizes the canonical representation.
The main advantages of using S-expressions in the preferred embodiment are:
A formal description of the policy specification language 108 is provided herein below in Table C.
<hash-atom> ::= <hex-string>
( <num-compare-op>
( <rng-compare-op>
( <member-compare-op>
)
( <bool-monadic-op> <bool-expr> ) |
( <bool-list-op> <bool-list> )
( union <union-list> )
[Some set of terminals of type
agent
—
directive
—
t]
( log-directive <log-severity> )
( protocol <union> ) |
( protocol <meta-value> )
( action <union> ) |
( action <meta-value> )
( initiator <cred-name> ) |
( initiator <meta-value> )
( target <cred-name> ) |
( target <meta-value> )
In the preferred embodiment the policy specification language 108 is typed. The policy compiler 101 performs the necessary type checking of all S-expressions found in a policy specification 107. Typing aids in catching and diagnosing both common and subtle user errors. A preferred embodiment of the type information is described herein below in Table D.
match - a type that is required to be the same as all other
The following table lists the typed attributes used in conditions and credentials.
The table below lists all the operations in the language that return a dynamic result. For each operation it shows both argument and result types
1Operator only supports types int_t and version_t as arguments.
The table below is pushing the concept of “type” far beyond its normal meaning since, in it, we often use type merely to convey positional information. It shows the type of every object in the language and the types of their arguments.
It is noted that the list of credential and condition attributes included in Table D is by no means complete. In other embodiments, the set of attributes is expanded or reduced to reflect the set of protocols supported by the Policy Monitoring System.
It is noted that although the remainder of this disclosure describes the specification language 108 by means of examples, and that for improved readability, said examples use the advanced rather than the canonical representation of S-expressions, this is not meant to further limit the invention.
In the preferred embodiment of the invention, the language 108 allows for comments to be embedded in S-expressions. A comment is allowed anywhere whitespace is valid. A comment begins with “//” and continues to the end-of-line. In compilation, comments are ignored because they serve merely as an aid to the human user.
In the preferred embodiment of the invention, the language 108 allows for external files to be included using the #include syntax of C. Included files are supported to enhance modularity and reusability of policy language segments.
In the preferred embodiment of the invention, the language 108 allows for macros to be defined using the #define syntax of C. Macros are supported to enhance readability. By convention, macros start with an uppercase letter but need not be fully capitalized.
The language 108 comprises the following first-class objects:
In the preferred embodiment first-class objects have names. Names are normally used to refer to an object from another object. By convention, names of built-in objects start with a lowercase letter and use hyphens (−) to separate words. Names of user-defined objects start with an uppercase letter and use intercaps or underscores (_) to separate words, but do not use hyphens. Names of data types start with a lowercase letter and end with an underscore followed by a lowercase ‘t’ (_t).
In the preferred embodiment a named object must be defined before its name can be used. The scope of a name is that of the entire policy specification as defined by the policy object.
In the preferred embodiment first-class objects may optionally include a description field. The description provides human readable text associated with the object. Unlike comments, description fields are preserved by the policy parser. When using the advanced representation, description strings may be split across several lines, using the C rules of string concatenation. That is, following the description token are one or more character strings, each enclosed in a set of double quotes.
Policy
In the preferred embodiment a policy is the top-most object defined by the specification language 108 and includes all other first-class objects. A policy manager may load several policies into its internal database. However, at any one point in time, only one active policy is in effect. That is the policy known to the Policy Engine 101. Following is an example of a policy object.
In the preferred embodiment a policy object has two mandatory parameters: name, which is used to reference the policy, and version number, which defines the version of the policy specification language 108. A policy's version number is used to check for compatibility between a policy specification and a policy compiler.
Groups and Unions
In the preferred embodiment groups are named collections of a given type. The union object creates the collection from a set of items. The group object gives the union a name and a type. Following is an example expressing a collection of colors:
In the example, the object identifies RED, GREEN and YELLOW as items, i.e. symbols, of type color_t (a fictitious data type) collected in a set named SomeColors. By convention, symbols defined in unions are fully capitalized.
In the preferred embodiment once a symbol is identified as being of a certain type, it is transparently added to an unnamed set of items of that type. It may then be reused in other unions, groups or wherever an individual item of that type is valid. For example, a valid way to define another group is as follows:
However in the preferred embodiment the following group would not be allowed since RED would already have been tagged as being of type color_t.
In the preferred embodiment sets can be combined with other predefined sets. For example,
It is noted that RED overlaps both SomeColors and RedByAnyOtherName, which according to the invention is perfectly acceptable. The resulting set will include only one instance of the set item RED.
In the preferred embodiment unions are similar to the C enum type, with the added benefit that unions can be combined and extended without concern for conflicting item values.
In a preferred embodiment unions are used, but are not limited to, to define collections of items, such as, for example, IP addresses, MAC addresses, integers, version numbers and hash values. That is, unions can define any data item that has a primitive data type in the language. An example of a group of IP addresses is defined as:
In the preferred embodiment the type of the items in the union must agree with the type specified in the group.
In a preferred embodiment, groups are referenced from other first-class objects. For example, groups are typically used to define collections of protocol actions, SSL ciphersuites, and IP addresses. Note that wherever a group is allowed, the following are also valid:
A list of built-in groups is given in section Table A.
Credentials
In the preferred embodiment a credential is a statement about a principal in a protocol event. It consists of a logical expression containing one or more assertions about the attributes that make up a principal's credentials. When a policy rule is evaluated against a protocol event, the credentials presented in the protocol event are compared to the credentials specified in a purported credential object. If the logical expression defined in the credential object is satisfied, the principal's presented credentials are said to satisfy the purported credentials. As an example, the following purported credentials are satisfied if the principal's IP address is 207.5.63.8 and its IP port number is either 80 or greater than 443.
In the preferred embodiment each protocol has a set of attributes that may be used to build purported credentials. Table E herein below lists all the attributes currently defined and, for each attribute, it shows the protocols where the attribute might be included in the presented credentials, as well as the operations where the attribute may be used as an operand.
2Can be used to identify the reporting Agent in any policy rule but must not be mixed with other credential attributes.
It is noted that the list of credential attributes included in Table E is by no means complete. In other embodiments, the set of attributes is expanded or reduced to reflect the set of protocols supported by the Policy Monitoring System.
In the preferred embodiment each attribute can be thought of as having an implied getter function that returns its value. Most attribute getters take no arguments and return a single value. In the preferred embodiment, however, some attribute getters (e.g. http-req-hdr and http-cookie) are functions that take one or more arguments and may return complex results. For example, http-cookie takes as an argument the name of a cookie in an HTTP request header and returns its value or values as a union of strings.
In the preferred embodiment it is important not to mix credential attributes from different protocol sets in a credential specification. For example, combining ip-address and der-cert in the same credential object would be an error and flagged by the policy compiler. As another example, using a credential in a policy rule for a protocol action that is incompatible with the credential attributes in the credential object is considered an error, flagged by the policy compiler. However, it is possible to use those attributes in two separate credential objects and establish relationships between them within policy rules (e.g. access to resource X is restricted to principals previously authenticated with credentials Y). See example Check_Access_Denial herein below for an example of establishing this type of relationships in policy rules.
In the preferred embodiment the credential attribute agent-attribute is used to define the credentials of the Agent 102 reporting the protocol event 103. Agents are individually configured with a set of attributes, which are used to identify them to a policy manager. In another embodiment, some agent attributes might uniquely identify a specific Agent (e.g. MONITOR_NEXT_TO_ROUTER_X) while others might identify a group of Agents (e.g. ALL_MONITORS_IN_SUBNET_Y).
The agent-attributes attribute returns a union of identification attributes for the reporting Agent 102. In the preferred embodiment within a credential specification, assertions about agent attributes may not be mixed with assertions about any other credential attributes.
Table F herein below lists all the operations used in a preferred embodiment to make assertions about attributes.
It is noted that the list of operations included in Table F is by no means complete. In other embodiments, the set of operations is expanded or reduced to reflect the set of protocols and features supported by the Policy Monitoring System.
In the preferred embodiment credentials may be combined with other credentials or with additional assertions. Consider the following example:
The example herein above defines purported credentials that will be satisfied if either Credentials_Example—1 is satisfied or if the presented credentials' IP address falls within the subnetwork defined by the address prefix 207.5.0.0/16 and if the IP port is between 25 and 443, inclusive.
In the preferred embodiment the absence of an assertion about a specific attribute in a credential specification indicates that its value is to be ignored in considering the presented credentials. In the preferred embodiment, it is often useful to indicate that a particular attribute must or must not be specified in the presented credentials, irrespective of the attribute's value, if any. The operations absent and present accomplish this, as illustrated by the following examples:
Conditions
In the preferred embodiment a condition defines a constraint upon a protocol event 103. Said condition comprises a logical expression containing one or more assertions about attributes of the protocol event. Policy rules use conditions to specify particular constraints that must or must not be satisfied by the protocol event 103.
Table G lists attributes of a protocol event 103 that may be used when formulating conditions. For each attribute the table shows protocols for which the attribute is defined, as well as the operations which can take the attribute as an operand.
It is noted that the list of condition attributes included in Table G is by no means complete. In other embodiments, the set of attributes is expanded or reduced to reflect the set of protocols and features supported by the Policy Monitoring System.
In the preferred embodiment operations listed in Table G may be used to build assertions about condition attributes.
In the preferred embodiment condition attributes cannot mix with those from different protocol sets in a condition specification. A condition used in a policy rule for a protocol that is incompatible with the condition attributes in the condition object is considered an error and is flagged by the policy compiler. For example, it is illegal to use ssl-ciphersuite in a condition referenced by a policy rule for HTTP.
Following are some examples:
Herein above, the condition SslV3StrongCiphers can be used with an SSL protocol event to ensure that SSL 3.0 or higher is used, that the negotiated ciphersuite is one of the strong RSA-based ciphersuites, that the RSA key-encipherment key has a modulus of no less than 768 bits, and that the RSA authentication key has a modulus of no less than 1024 bits.
Herein above, the condition HackerTripwire can be used with any protocol event 103 to ensure that the active principal 141 is not a potential attacker. The third condition, ProtectSSL, simply combines the first two.
Dispositions
In the preferred embodiment a disposition defines an outcome of a policy rule. Each policy rule may have many possible outcomes depending on, for example, constraints imposed on the protocol event.
See Table H herein for a list of disposition codes and an explanation of their meanings in the preferred embodiment.
It is noted that the list of disposition codes included in Table H is by no means complete. In other embodiments, the set of disposition codes is expanded or reduced to reflect the set of features supported by the Policy Monitoring System.
Table I herein below lists possible severity codes in the preferred embodiment.
It is noted that the list of severity codes included in Table I is by no means complete. In other embodiments, the set of severity codes is expanded or reduced to reflect the set of features supported by the Policy Monitoring System.
Table J herein below lists possible agent directives in the preferred embodiment.
It is noted that the list of agent directives included in Table J is by no means complete. In other embodiments, the set of agent directives is expanded or reduced to reflect the set of features supported by the Policy Monitoring System.
Following are examples of preferred embodiments of dispositions:
The Ok_Monitor disposition is used to dispose of a valid network event 103 while flagging a logging subsystem that this event should be logged at a low severity level (MONITOR).
The Continue_Decrypt disposition is used to inform the Policy Engine 101 that additional information is needed from the Agent 102 before determining a final disposition 105 for the network event 103 while, at the same time, instructing an appropriate Agent to decrypt all traffic at a current protocol layer.
The Access_Denied disposition is used as a final disposition 105 for a network event 103. It denotes a policy violation.
A list of built-in dispositions of the preferred embodiment is provided herein above in Table A.
Rules
In the preferred embodiment a rule object defines a policy rule. A policy rule governs a specific interaction, or set of interactions, between two communicating entities. The Policy Engine 101 evaluates policy rules against protocol events to determine if the latter conform to the active security policy. Following is an example of a policy rule according to a preferred embodiment of the invention:
In the preferred embodiment a policy rule comprises:
In the preferred embodiment each outcome section comprises one or more conditional statements, each followed by a disposition. The purpose of conditional statements is to specify constraints upon a protocol event, or special conditions that, if satisfied, cause the generation of an alternate disposition for the protocol (or network) event. Conditional statements are evaluated in the order in which they are specified within the outcome section.
In the preferred embodiment a conditional statement starts with one of the following keywords:
The following examples illustrate the use of prerequisites in rules in a preferred embodiment. The first rule is the prerequisite.
Herein above, the rule Access_Host_A states that access to host A on port 80 by any host is denied, unless explicitly allowed by a rule at a higher protocol layer. Note the use of a final outcome, which is only evaluated if Access_Host_A becomes the applicable rule for the entire network event. The implied disposition for the protocol event is CONTINUE.
This rule can be overridden by another rule at the HTTP layer stating that access is allowed to host A on port 80, as shown below:
The end result of the two policy rules herein above is to prevent all access to host A on port 80 unless that access is using HTTP over TCP/IP.
In the preferred embodiment a prerequisite rule is any rule that is selected for a previous protocol event. This includes rules in the same protocol layer. As an example, to ensure that a web server requires HTTP authentication before allowing access to a specific web page, use the following rules:
The example herein above shows that access to the document sub-tree identified by Some_Url requires the user be authenticated using basic HTTP authentication. The authentication is accomplished by means of the condition Require_Auth which, in the context of rule Check_Access_Denial, checks that the server returns an Unauthorized status code. If the server fails to do so, the Access_Denied disposition is generated. Note that the prerequisite constraint ensures that the rule Check_Access_Denial is only considered if the rule Host_A_Anon_Access is selected when the HTTP request event is evaluated, that is, requests where basic HTTP authentication is not used.
The Policy Specification Process
In the preferred embodiment the policy specification process comprises the following steps:
1) Identify communicating entities recognized by the security policy. The entities comprise physical networks and sub-networks, host machines, communication protocols, users, applications, services, and any other resources of interest.
2) Identify relationships between the communicating entities and define rules to control said relationships (e.g. host A may communicate with host B but not with host C).
3) Formally define communicating entities and entity relationships using the policy specification language (
4) Compile the policy specification with a Policy Compiler (
The annotated policy specification 107 is suitable for loading into the Policy Engine 101 for evaluation of one or many network events 103, or back into the graphical policy editor for visualization and further refinement.
Evaluation of Rules
This section describes how policy rules are organized and evaluated according to the invention.
Policy Evaluation Model
The policy specification language 108 alone does not describe how the Policy Engine 101 evaluates policy rules. In the preferred embodiment of the invention, a security administrator that writes the policy specification 107 and the Policy Engine 101 that enforces the policy specification 107 share a common view of the evaluation procedure. The evaluation of policy rules is deterministic.
In the preferred embodiment of the invention the basic policy specification language 108 is augmented to convey information about how rules are ordered for purposes of evaluation, i.e. which rules are evaluated first and which rules are selected for any given network event. The augmented language is a superset of the basic specification language 108 and it is hereinafter referred to as the annotated specification language 109.
In one embodiment the security administrator uses the annotated specification language 109 using a visual tool, such as a graphical policy editor to determine how the policy rules are interrelated, their hierarchical relationships and how they will be evaluated. This step is crucial to determining whether the specified policy correctly reflects the desired security policy and to identifying areas where the policy specification needs refinement.
In the preferred embodiment the Policy Engine 101 uses the annotated language 109 to organize the policy, after having converted it to an internal representation in a manner best suited for the efficient evaluation of network events.
In the preferred embodiment the Policy Engine 101 receives protocol events in proper sequence. Protocol events for protocols lower in the protocol stack are received before protocol events for protocols higher in the stack. This sequencing is important because the Policy Engine 101 must make a policy decision about, for example, a TCP connection, before it makes a decision about an SSL session that uses that TCP connection.
Data about a specific protocol event may not arrive all at once. For example, when evaluating an SSL session the Policy Engine 101 first receives the server certificate and negotiated ciphersuite before receiving a client certificate or a message indicating that none was provided. In a preferred embodiment, the Policy Engine 101 uses incomplete information about a protocol event in order to collect a set of possible policy rules applicable to that event. However, for the sake of simplicity, the remainder of this document assumes that Agents convey information about protocol events in an atomic manner.
In the preferred embodiment for every protocol event the Policy Engine 101 selects a policy rule applicable to that event. Every policy rule is associated with a specific protocol and action or a set of protocols and actions. Therefore only the set of rules relevant to the protocol event is considered. Of that set, several rules can be satisfied by the event. In the preferred embodiment a policy rule is satisfied by a protocol event if the following holds true:
1) The credentials of the Agent 102 reporting the event match the rule's agent credentials (if any), defined as a set of attribute-value assertions.
2) The rule's protocol specifier matches the protocol identifier in the protocol event.
3) The rule's action specifier matches the action identifier in the protocol event.
4) The rule's prerequisite clause is satisfied (details described herein below).
5) The credentials of the initiator 141 and target 142 principals in the protocol event satisfy the rule's corresponding credentials, defined as a set of attribute-value assertions.
In the preferred embodiment when several rules are satisfied by a protocol event, the Policy Engine 101 selects a rule that is most specific to the protocol event. The specificity of a policy rule is determined by the specificity of the credentials associated with the policy rule, as well as the specificity of the rule's protocol, action and prerequisite specifiers. For example, a rule that targets one single protocol is more specific than a rule that targets all protocols. In another example, a rule that specifies a prerequisite is more specific than a rule that does not.
In the preferred embodiment the specificity of a credential specification is determined by the set relationships of said specification with other credential specifications. Following are examples of credential specifications:
B defines the intersection of A and C, i.e. B is a subset of both A and C. Thus, B is more specific than either A or C.
According to the invention, in general, the more data described about a principal the more specific are the credentials. In the preferred embodiment, some attributes of a principal's credentials have more importance than do other attributes of the credentials. In the preferred embodiment the importance of an attribute is represented by its weight. The attribute weight is determined by its role as a discriminator of principals. For example, an attribute that yields a small set of principals has more weight than an attribute that yields a larger set of principals. In the hair and eye color example herein above, it is arbitrary to give a higher weight to eye color versus hair color or to give both hair and eye color the same weight. Assigning an attribute weight is easier because typically protocol credentials are structured hierarchically. For example, in the TCP protocol, the IP address attribute has clearly more weight than the IP port attribute because the number of principals with a given IP address is generally much smaller than the set of principals with a given port number.
In the preferred embodiment attributes that comprise a set of credentials are ranked by weight and the combined weight of all attributes in a credential specification is considered in determining a relative specificity of said specification.
In the preferred embodiment a policy specification has sets of credentials each of which are ranked at a same specificity level, thereby rendering many policy rules that are applicable to a given protocol event. Herein below is provided a section describing a number of practical guidelines for good policy development that minimize herein above ambiguities.
a is a schematic diagram of the preferred embodiment in which a network event 103 comprises M protocol events at different protocol layers, and in which the network event 103 has an associated network event disposition 105.
b is an algorithm showing how the M protocol events at different protocol layers of the network event 103 result in pending rules with or without immediate outcomes and, finally, a final disposition for the network event 105. For clarity, the algorithm assumes that the Policy Engine 101 always finds a policy rule applicable to a given protocol event, that at least a first Protocol Event (1) exists, and that the algorithm ends when the Agent 102 informs the Policy Engine 101 that no further protocol events will be generated. These assumptions are for clarifying purposes only and do not limit the invention in any way.
The algorithm begins with j=1 (500) and with the Policy Engine 101 receiving Protocol Event (1) from the Agent 102 (501) (502).
Once a most specific policy rule is selected for a given protocol event (503), the Policy Engine 101 consults an outcome clause (504) determining if an immediate outcome is applied to the protocol event. In the preferred embodiment an immediate outcome applies to a protocol event while a final outcome applies to a network event (103).
In the preferred embodiment an immediate outcome is executed when it is specified. The immediate outcome can evaluate constraints (i.e. conditions) against a protocol event, produce a set of agent directives (e.g. instructing the Agent 102 to decrypt all subsequent traffic), and produce a final disposition (506) for the protocol event rendering said disposition for the entire network event. When a disposition of an immediate outcome is not a final disposition, a special disposition code, CONTINUE, is used as an indicator. All disposition codes other than CONTINUE denote final dispositions.
In the preferred embodiment when an immediate outcome does not produce a final disposition the associated selected policy rule becomes a pending policy rule for the related network event (507). The Policy Engine 101 then waits for further protocol events of the network event 103 from the Agent 102 (508) and (501). In this embodiment, said pending policy rule is overridden by subsequent policy rule selected for a protocol event higher in the associated protocol stack (507).
In the preferred embodiment policy evaluation ends in one of two cases. First case is when no further rules in the policy apply to a network event (e.g. a highest protocol in the stack is reached). Second case is when the Agent 102 informs the Policy Engine 101 that no further protocol events will be generated (502) (509) (506) (510). In either case, a policy decision is then expected for the entire network event. The Policy Engine 101 selects a pending policy rule for a protocol highest in the protocol stack and executes the final outcome defined for that rule (511). In the preferred embodiment constraints are evaluated against the entire network event. In the preferred embodiment a final outcome always produces a final disposition (509) which becomes a disposition for the network event (506).
In the preferred embodiment a protocol event must result in a selection of a policy rule (pending or final). When a policy rule applicable to a given protocol event is not found, the Policy Engine 101 produces a special disposition identifying a policy specification error. See the default policy rule in Table A.
Ordering of Credentials
In the preferred embodiment credentials are ordered based on a combined weight of all attribute-value assertions that make up a credential specification.
In the preferred embodiment computing a weight of an attribute-value assertion of an attribute requires the following two steps:
1) Assigning a ranking value to the attribute. Attributes that are listed in a credential specification are ranked against each other. Ranking is based on a value of the attribute as a discriminator of principals identified by the credentials. If the presence of the attribute in a credential specification generally yields a smaller set of principals than the presence of another attribute, then the former has a higher ranking than the latter.
2) Assigning a ranking value to an assertion type of the attribute. An assertion type is used to make an assertion about the value of an attribute (e.g. eq, substring, range). Following are five assertion types, in decreasing ranking order:
Table K herein below shows the preferred embodiment assertion types for all operations that operate on attributes to build assertions. In the preferred embodiment when a credential specification does not include any assertions about a particular attribute then the assertion type for that attribute is ignore.
In the preferred embodiment assertions in a credential specification often are combined using logical operators and, or and not. For example,
In the preferred embodiment a weight assigned to a credential specification is derived from a combined weight of all assertions the credential specification comprises. An algorithm herein below is used recursively to compute a combined weight of a set of assertions operated on by a logical operator:
A. An operator not does not affect the weight of its operand.
B. An operator and creates a union of weights of all its operands. The weights are sorted in decreasing order of attribute rank. If multiple assertions are made about a particular attribute, use a weight of a most specific assertion and discard all other weights for that attribute. If multiple distinct assertions (i.e. not identical or equivalent) are made about a particular attribute at a same level of specificity, the assertions are enumerated. In general, the higher a number of distinct assertions made about an attribute the more specific is a credential specification. For example, the two assertions “hair is not black” and “hair is not brown” when combined in a union are more specific than either individual assertion.
C. An operator or results in a selection of an operand with a lowest weight. In addition said combined weight is penalized, such that it weighs less than the associated assertion with the lowest weight. If two or more assertions of equal weight are combined with or, the combined weight is lower than that of either or any individual assertion. The rationale behind the penalty is that, in general, combined assertions yield a larger set of principals (i.e. is less specific) than each assertion by itself. The weight penalty is associated with the entire credential specification, not with an individual assertion or set of assertions. Thus, for every instance of the operator or in the credential specification, the weight penalty is incremented by one.
In the preferred embodiment a 3-tuple represents a weight of all attribute-value assertions about a specific attribute within a credential specification. Elements in the 3-tuple are:
In the preferred embodiment the 3-tuple is represented by a weight S-expression in the annotated specification language. A syntax of this expression is:
In the preferred embodiment ranking of assertion types is fixed and defined by the Table L following:
In the preferred embodiment ranking of an attribute is configurable by a security administrator and must be defined prior to a compilation of a policy specification. Attribute ranking is communicated to the policy compiler in a variety of ways. Table M herein below shows a preferred embodiment of proposed rankings for attributes used in credentials for all supported protocols. Said rankings are assumed in examples used throughout the remainder of this document. It is noted that a credential attribute agent-attributes cannot be used in a specification of an initiator or target credential and therefore need not be ranked. It is further noted that the special assertions true and false, which are allowed by the policy specification language's grammar in the preferred embodiment, do not apply to any specific attribute and, thus, are assigned a special weight consisting of a zero valued attribute rank, a zero valued assertion type rank and a zero valued attribute assertion count.
In the preferred embodiment an attribute assertion count starts at zero for a first assertion and is incremented monotonically for all subsequent assertions. That is, the count enumerates additional assertions for the attribute. In the preferred embodiment the assertion count is omitted from the weight S-expression when said count is zero.
In the preferred embodiment a weight S-expression is omitted when an assertion type is ignore.
In the preferred embodiment the three elements of a 3-tuple are used in sorting a collection of 3-tuples. The attribute rank as a primary key, the assertion type rank as a secondary key, and the attribute assertion count as a tertiary key produce an ordered list of 3-tuples sorted in decreasing order of rank and count. In the preferred embodiment said sorted list is used to rank credential specifications against each other. The sorting algorithm is described using pseudo-code in Table N herein below:
A weight penalty is represented by the following S-expression in the annotated specification language:
Thus, Credentials_Example—1 herein above is annotated as follows:
In the preferred embodiment a credential specification can combine previous credential specifications with each other or with additional assertions. In the preferred embodiment rules for a combination of assertions with logical operators apply equally to a combination of credential specifications. For example:
The weight of Credentials_Example—2 is:
The weight of Credentials_Example—3 is:
In the embodiment to compute the weight of Credentials_Example—4 first compute a weight of the or expression. Credentials_Example—1 is selected as having a lowest weight because of an associated weight penalty. Furthermore, the or expression in Credentials_Example—4 increases the weight penalty further, yielding:
In the embodiment the and expression adds an additional, distinct, assertion about ip-port. The assertion is of the same type as one currently selected because they are both multi-value assertions. The assertion count for ip-port is incremented, yielding:
In the embodiment a ranking algorithm for comparing and ordering credentials is implied in the example previously described herein above. Following in Table O is an associated algorithm using pseudo-code:
The following Table P ranks example credentials according to the preferred embodiment using the algorithm herein above. A weight column shows 3-tuples using a format W:x,y,z, wherein x is an integer value for an attribute rank (Table M), y is an integer value for an assertion type (Table P), and z is an assertion count. A weight penalty is shown as P:x, wherein x is a penalty count. It is noted that the higher a rank of a credential specification, the more specific it is. For completeness, the table includes ranking for built-in credentials denoted by absent, present and ignore. Said built-in credentials make assertions about and in the order of an absence, presence, and irrelevance of any credentials presented by a protocol event. It is noted that in the preferred embodiment ignore and present always rank lower and absent higher than do any user-defined credentials.
Ordering of Rules
In the preferred embodiment policy rules must be organized such that when two or more rules are satisfied by a protocol event, the most specific rule for that event is selected. The specificity of a policy rule is fully determined by the specificity of the credentials it uses.
In the preferred embodiment policy rules are organized as follows:
In the preferred embodiment and because rules are ranked directly from the ranking of their credentials, a special representation is not provided in the annotated specification language for the ranking of the policy rules.
Following is an example using credentials from herein above:
Table Q herein below shows how said rules are ranked according to the invention.
It is noted that Rule_Example—1 and Rule_Example—2 are ranked at the same specificity level. This does not represent a problem because the respective initiator and target credential sets are non-intersecting and used in different roles.
In the preferred embodiment it is possible for two or more rules at a same specificity level to be satisfied by a single protocol event. During policy specification a security administrator disambiguates the evaluation of rules with the same specificity level by forcing a ranking order among them. Forcing a ranking order is done by specifying that one rule is ranked above another rule and is termed forced ranking. Forced ranking is expressed by means of the following S-expression:
For example, to give Rule_Example—2 precedence over Rule_Example—1, the following S-expression is added to a definition of Rule_Example—2:
In the preferred embodiment after performing the standard ranking algorithm herein above, the Policy Engine 101 evaluates all rank-above expressions and reassigns ranking numbers to each rule accordingly. In the preferred embodiment it is important to note that forced ranking does not force a ranking of an affected rule to a level of a more specific rule higher in the ranking order. Instead a new ranking level is created for the affected rule and all other ranking numbers of more specific rules are incremented accordingly.
For example, Rule_Example—2 herein above is given ranking number 2 and the ranking number of Rule_Example—3 herein above is incremented from 2 to 3.
In the preferred embodiment forced ranking is applied to any rule and is not limited by rules having only non-unique ranking numbers. In this embodiment security administrators are cautioned not to use said forced ranking feature unless absolutely necessary. Its misuse may result in a policy specification that is both difficult to manage and difficult to evaluate. In the preferred embodiment runtime conflicts in the evaluation of rules (i.e. when a protocol event is satisfied by multiple rules) typically can be solved by redesigning credentials upon which said rules are based. Useful tips are provided herein below.
Evaluation Algorithm
In the preferred embodiment the Policy Engine 101 applies a policy evaluation algorithm to each incoming protocol event. The algorithm results in a selection of a policy rule applicable to the protocol event and may produce an immediate or final disposition.
Following is a step-by-step description of the evaluation algorithm according to the preferred embodiment. It is noted that the evaluation procedure described herein below is in conceptual form and does not take into account any possible runtime optimizations:
The outcome of the policy evaluation algorithm herein above is a policy rule that satisfies the protocol event. If an immediate outcome is specified for that rule, it is executed, producing a disposition for the protocol event. If the disposition comprises a final disposition code (any code other than CONTINUE), the disposition is also the final disposition for the network event.
Otherwise in the preferred embodiment the selected policy rule is a pending policy rule for the network event. In absence of any further protocol events the pending policy rule is promoted to selected policy rule. A final outcome of the selected policy rule is executed producing a final disposition for the network event.
Policy Specification Guidelines
Provided herein below in Table R are a number of practical guidelines coupled to the preferred embodiment for the development and specification phases of a security policy. Adhering to the guidelines ensures efficient and accurate evaluation of a policy by the Policy Engine 101. It is intended to incorporate the guidelines into a graphical policy editing invention using wizards, policy templates and other UI mechanisms that among other uses simplify and direct the policy specification process.
Although the invention is described herein with reference to a variety of preferred embodiments, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the Claims included below.
This application is a continuation of the U.S. patent application Ser. No. 09/479,781, filed Jan. 7, 2000 now U.S. Pat. No. 6,779,120, the contents of all of which are incorporated by reference herein by the reference thereto.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4860203 | Corrigan et al. | Aug 1989 | A |
| 5262956 | DeLeeuw | Nov 1993 | A |
| 5513305 | Maghbouleh | Apr 1996 | A |
| 5555346 | Gross et al. | Sep 1996 | A |
| 5557747 | Rogers et al. | Sep 1996 | A |
| 5627764 | Schutzman et al. | May 1997 | A |
| 5644766 | Coy et al. | Jul 1997 | A |
| 5679940 | Templeton et al. | Oct 1997 | A |
| 5701400 | Amado | Dec 1997 | A |
| 5751965 | Mayo et al. | May 1998 | A |
| 5781629 | Haber et al. | Jul 1998 | A |
| 5796942 | Esbensen | Aug 1998 | A |
| 5805899 | Evans et al. | Sep 1998 | A |
| 5819226 | Gopinathan et al. | Oct 1998 | A |
| 5825361 | Rubin et al. | Oct 1998 | A |
| 5867483 | Ennis, Jr. et al. | Feb 1999 | A |
| 5870561 | Jarvis et al. | Feb 1999 | A |
| 5872928 | Lewis et al. | Feb 1999 | A |
| 5875334 | Chow et al. | Feb 1999 | A |
| 5878426 | Plasek et al. | Mar 1999 | A |
| 5887139 | Madison, Jr. et al. | Mar 1999 | A |
| 5924089 | Mocek et al. | Jul 1999 | A |
| 5960460 | Marasco et al. | Sep 1999 | A |
| 5968176 | Nessett et al. | Oct 1999 | A |
| 5978475 | Schneier et al. | Nov 1999 | A |
| 5983270 | Abraham et al. | Nov 1999 | A |
| 5987611 | Freund | Nov 1999 | A |
| 5991713 | Unger et al. | Nov 1999 | A |
| 5991876 | Johnson et al. | Nov 1999 | A |
| 5991877 | Luckenbaugh | Nov 1999 | A |
| 6009475 | Shrader | Dec 1999 | A |
| 6026397 | Sheppard | Feb 2000 | A |
| 6049621 | Jain et al. | Apr 2000 | A |
| 6058193 | Cordery et al. | May 2000 | A |
| 6064304 | Arrowsmith et al. | May 2000 | A |
| 6064810 | Raad et al. | May 2000 | A |
| 6065119 | Standford, II et al. | May 2000 | A |
| 6069563 | Kadner et al. | May 2000 | A |
| 6091835 | Smithies et al. | Jul 2000 | A |
| 6108782 | Fletcher et al. | Aug 2000 | A |
| 6119103 | Basch et al. | Sep 2000 | A |
| 6131163 | Wiegel | Oct 2000 | A |
| 6134532 | Lazarus et al. | Oct 2000 | A |
| 6154775 | Coss et al. | Nov 2000 | A |
| 6157707 | Baulier et al. | Dec 2000 | A |
| 6158010 | Moriconi et al. | Dec 2000 | A |
| 6212558 | Antur et al. | Apr 2001 | B1 |
| 6212677 | Ohkubo et al. | Apr 2001 | B1 |
| 6263349 | Anderson | Jul 2001 | B1 |
| 6269447 | Maloney et al. | Jul 2001 | B1 |
| 6271845 | Richardson | Aug 2001 | B1 |
| 6279037 | Tams et al. | Aug 2001 | B1 |
| 6292900 | Ngo et al. | Sep 2001 | B1 |
| 6301668 | Gleichauf et al. | Oct 2001 | B1 |
| 6317788 | Richardson | Nov 2001 | B1 |
| 6324590 | Jeffords et al. | Nov 2001 | B1 |
| 6389481 | Malcolm | May 2002 | B1 |
| 6400707 | Baum et al. | Jun 2002 | B1 |
| 6442615 | Nordenstam et al. | Aug 2002 | B1 |
| 6453345 | Tricka et al. | Sep 2002 | B2 |
| 6463470 | Mohaban et al. | Oct 2002 | B1 |
| 6466976 | Alles et al. | Oct 2002 | B1 |
| 6484143 | Swildens et al. | Nov 2002 | B1 |
| 6484261 | Wiegel | Nov 2002 | B1 |
| 6493694 | Xu et al. | Dec 2002 | B1 |
| 6499107 | Gleichauf et al. | Dec 2002 | B1 |
| 6502131 | Vaid et al. | Dec 2002 | B1 |
| 6505192 | Godwin et al. | Jan 2003 | B1 |
| 6505245 | North et al. | Jan 2003 | B1 |
| 6519767 | Carter et al. | Feb 2003 | B1 |
| 6523027 | Underwood | Feb 2003 | B1 |
| 6526044 | Cookmeyer et al. | Feb 2003 | B1 |
| 6546493 | Magdych et al. | Apr 2003 | B1 |
| 6578077 | Rakoshitz et al. | Jun 2003 | B1 |
| 6598034 | Kloth | Jul 2003 | B1 |
| 6606710 | Krishnan et al. | Aug 2003 | B2 |
| 6636873 | Merchant et al. | Oct 2003 | B1 |
| 6651099 | Dietz et al. | Nov 2003 | B1 |
| 6665725 | Dietz et al. | Dec 2003 | B1 |
| 6704873 | Underwood | Mar 2004 | B1 |
| 6711699 | Kanevsky et al. | Mar 2004 | B1 |
| 6715081 | Attwood et al. | Mar 2004 | B1 |
| 6725281 | Zintel et al. | Apr 2004 | B1 |
| 6738933 | Fraenkel et al. | May 2004 | B2 |
| 6757714 | Hansen | Jun 2004 | B1 |
| 6771646 | Sarkissian et al. | Aug 2004 | B1 |
| 6779120 | Valente et al. | Aug 2004 | B1 |
| 6789116 | Sarkissian et al. | Sep 2004 | B1 |
| 6792458 | Muret et al. | Sep 2004 | B1 |
| 6816903 | Rakoshitz et al. | Nov 2004 | B1 |
| 6816973 | Gleichauf et al. | Nov 2004 | B1 |
| 6839751 | Dietz et al. | Jan 2005 | B1 |
| 6901442 | Schwaller et al. | May 2005 | B1 |
| 6954789 | Dietz et al. | Oct 2005 | B2 |
| 7007301 | Crosbie et al. | Feb 2006 | B2 |
| 7020697 | Goodman et al. | Mar 2006 | B1 |
| 7047423 | Maloney et al. | May 2006 | B1 |
| 7143439 | Cooper et al. | Nov 2006 | B2 |
| 7228566 | Caceres et al. | Jun 2007 | B2 |
| 20010014150 | Beebe et al. | Aug 2001 | A1 |
| 20010054097 | Chafe | Dec 2001 | A1 |
| 20020108059 | Canion et al. | Aug 2002 | A1 |
| 20020184525 | Cheng | Dec 2002 | A1 |
| 20020188584 | Ghannam et al. | Dec 2002 | A1 |
| 20030212909 | Chandrashekhar et al. | Nov 2003 | A1 |
| 20040019803 | Jahn | Jan 2004 | A1 |
| 20050005169 | Kelekar | Jan 2005 | A1 |
| 20050015622 | Williams et al. | Jan 2005 | A1 |
| 20050195964 | Hahn et al. | Sep 2005 | A1 |
| Number | Date | Country |
|---|---|---|
| 0511437 | Nov 1992 | EP |
| 0782112 | Jul 1997 | EP |
| 0669032 | Nov 1997 | EP |
| 0849909 | Jun 1998 | EP |
| 0854621 | Jul 1998 | EP |
| 0893763 | Jan 1999 | EP |
| 0849909 | Feb 1999 | EP |
| 0909074 | Apr 1999 | EP |
| 0961440 | Dec 1999 | EP |
| 1006701 | Jul 2000 | EP |
| 1024627 | Aug 2000 | EP |
| 1026867 | Aug 2000 | EP |
| 1050833 | Nov 2000 | EP |
| 1143660 | Oct 2001 | EP |
| 2335829 | Sep 1999 | GB |
| WO 9311480 | Jun 1993 | WO |
| WO 9403859 | Feb 1994 | WO |
| WO 9826541 | Jun 1998 | WO |
| WO 9915950 | Jan 1999 | WO |
| WO 9922492 | May 1999 | WO |
| WO 9935583 | Jul 1999 | WO |
| WO 9967930 | Dec 1999 | WO |
| WO 0005842 | Feb 2000 | WO |
| WO 0035130 | Jun 2000 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20040250112 A1 | Dec 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09479781 | Jan 2000 | US |
| Child | 10869172 | US |
