Policy Anomalies - Policy Optimization - Rule Management Reports

Policy Anomalies

The Policy Anomalies sub-section in Firewall Analyzer provides a view of all the firewall policy anomalies reports. This section can be accessed from the Policy Optimization > Policy Anomalies link under the path Reports > Rule Management.

Refer the Rule Management Report Support page, for the list of firewall devices.

Policy Anomalies

Firewall Analyzer offers an exhaustive set of Firewall policy anomaly reports in the policy optimization section.

In the policy optimization sub-section, you get a variety of policy anomaly reports, which will aid you to optimize the performance of firewall policies.

The Rule Management Anomaly reports are, Correlation, Generalization, Grouping, Redundancy, and Shadow. The reports will be displayed in the graphical and tabular format.

Anomaly Classification

1. Shadow anomaly

A rule is shadowed when a previous rule matches all the packets that match this rule, such that the shadowed rule will never be evaluated. If the shadowed rule is removed, the security policy will not be affected
Rule Rx is shadowed by rule Ry if Rx follows Ry in the order, and Rx is a subset match of Ry and the actions of Rx and Ry are different
This might cause a permitted traffic to be blocked and vice versa. Hence it is an anomaly. It is important to discover shadowed rules and alert the administrator who might correct this error by re-ordering or removing the shadowed rule

Example:

Source	Destination	Service	Action
10.0.0.1-10.0.0.10	20.0.0.1-20.0.0.10	http,https	Allow
10.0.0.5	20.0.0.3	http	Deny

In this case, second rule will never get hit. It is shadowed. Also, action is different for both the Rules.

2. Redundancy anomaly

A redundant rule performs the same action on the same packets as another rule such that if the redundant rule is removed, the security policy will not be affected
Rule Rx is redundant to rule Ry if Rx is a subset match of Ry and the actions of Rx and Ry are similar
If removed, the effect of the resulting policy will be unchanged
Redundancy is considered an error. A redundant rule may not contribute in making the filtering decision, however, it adds to the size of the filtering table, and might increase the search time and space requirements.It is important to discover redundant rules so that the administrator may modify its filtering action or remove it altogether

Shadow and Redundant Rules are more or less similar. If Action differs it is shadow, otherwise it is redundant.

Case 1 (R1 is subset/equal of R2): Administrator can remove R1
Case 2 (R2 is subset of R1): Administrator can remove R2

Example:

Source	Destination	Service	Action
10.0.0.1-10.0.0.10	20.0.0.1-20.0.0.10	http,https	Allow
10.0.0.5	20.0.0.3	http	Allow

3. Correlation anomaly

Two rules are correlated if they have different filtering actions, and the first rule matches some packets that match the second rule and the second rule matches some packets that match the first rule
Rule Rx and rule Ry have a correlation anomaly if Rx and Ry are correlated and the actions of Rx and Ry are different
If the order of the two rules is reversed, the effect of the resulting policy will be changed

Example:

Source	Destination	Service	Action
10.0.0.5	20.0.0.1-20.0.0.10	http,https	Allow
10.0.0.1-10.0.0.10	20.0.0.3	http	Deny

From the above example, in Rule 1, HTTP Traffic from 10.0.0.5 to 20.0.0.3 is allowed. If you re-order this by moving the second to top and first rule to bottom, HTTP Traffic from 10.0.0.5 to 20.0.0.3 will be blocked. The effect of the policy has changed.
Correlation is considered an anomaly warning and no suggestion required. This anomaly has to be handled explicitly by the firewall administrator.

4. Generalization anomaly:

A rule is a generalization of another rule if the first rule matches all the packets that the second one could match but not the opposite
Rule Rx is a generalization of rule Ry, if Rx follows Ry in the order and Rx is a superset match of Ry and the actions of Rx and Ry are different
If the order of the two rules is reversed, the effect of the resulting policy will be changed

Example:

Source	Destination	Service	Action
10.0.0.5	20.0.0.3	http	Allow
10.0.0.1-10.0.0.10	20.0.0.1-20.0.0.10	http,https	Deny

In the above example, rule 2 is a generalization of rule 1. If the order of the two rules is reversed, the effect of the resulting policy will be changed and rule 1 will not be effective anymore, as it will be shadowed by rule 2. As a general guideline, if there is an inclusive match relationship between two rules, the superset (or general) rule should come after the subset (or specific) rule.
Generalization is considered only an anomaly warning because inserting a specific rule makes an exception of the general rule. The firewall administrator should handle it.

5. Rule Grouping

This is not an standard anomaly. It is additional one provided by Firewall Analyzer

Two rules can be grouped if and only if the actions of both the rules are same and any one component among source, destination and service varies between those two rules and remaining all are same
Say Rx and Ry have same destination, service and only source differs (source differs means neither be subset nor superset) then the suggestion is to group both the rules by defining a network object for both the source networks and can redefine a rule by using it.

Example:

Source	Destination	Service	Action
10.0.0.11-10.0.0.20	20.0.0.1-20.0.0.10	http,https	Allow
10.0.0.1-10.0.0.10	20.0.0.1-20.0.0.10	http,https	Allow

Administrator can create a network object with some name say 'InternalTest' and can remove both the rules and recreate it like below:

Source	Destination	Service	Action
InternalTest (or) 10.0.0.1-10.0.0.20	20.0.0.1-20.0.0.10	http,https	Allow

where InternalTest - 10.0.0.11-10.0.0.20 and 10.0.0.1-10.0.0.10 or instead of creating new network object it is suggested to group two rules with source as '10.0.0.1-10.0.0.20'.

Featured links