Optimize a Rule

1. Go to ManageSecurity PosturePolicy Optimizer.

   The Ready for Optimization tab lists all overly permissive rules for which recommendations are available. These rules are sorted by traffic volume, with the highest-hit rules appearing first. Review the overly permissive rules and select one to view its optimization recommendations. If multiple such rules exist, prioritize optimizing those with the highest traffic impact to achieve the most significant improvements in your security posture. You can remove a rule from optimization to prevent the Policy Optimizer from processing it. The rule settings remain as is.

2. Select a rule to see the optimization recommendations.

   You can see how much of the original rule’s traffic that each new rule will cover. Note the specific applications that each new rule enforces.

   You can view the optimized security rules by selecting one of the following parameters:

   • View by Overall Traffic
   • View by Session Count
   • View by Number of Unique Users

   All the rule recommendations suggested by Policy Optimizer are prepended by optrule and appended by an integer.
3. Accept some or all the rule recommendations.

   Accepting the new, optimized rules adds the rules to your rulebase. They won't be active yet; that will happen in the next step when you Push Config.

   Accept All accepts the recommended rules as they are. You can also make changes before accepting the optimized rules:

   • If you want to accept only specific rules, then you need to disable the remaining rules and Accept All the remaining rules. Disabling an optimized rule means that you're not accepting it, and it won’t be added to the rulebase.
   • Delete individual applications, application groups, or both in the Applications sidecar.
   • Remove a rule from optimization. Add this rule to a list of rules that you want to exclude from optimization (this time and moving forward).
   • Disable an optimized rule to indicate that you’re not accepting it. The rule won't be added to the rulebase and will be moved out of the recommendation rule list. Disable an optimized rule.
   • Revert any changes you’ve made. This undoes any edits you’ve made and reverts the rules back to the recommendations.
   • Merge rules. You might decide to do this if you find any of the recommended rules to be similar. Note that with the merging of rules, negated and unnegated addresses cannot be merged.
   • Create address groups within policy rule recommendations, addressing challenges in efficiently managing firewall policies at scale. You can create source and destination address groups within recommended rules, allowing you to adjust and preview suggested groups before accepting recommendations.

   The address group retains the original configuration scope. You can change it to the global configuration scope by checking the check box.

   After you accept the optimized rules, you’ll be prompted to Update Rulebase. When you agree, the optimized rules are added to your Security policy. However, they’re not yet enforcing traffic.

   When multiple uncovered public networks remain, Policy Optimizer uses negated RFC-1918 ranges. To make recommendations that are clear and manageable, it identifies existing address objects, groups, or standard subnets to suggest in the address fields. For example, instead of recommending 1,000 individual source IP addresses seen in traffic, Policy Optimizer suggests an address object like “user-addresses” (e.g., 10.5.0.0/16) if it matches, or a standard private subnet like RFC-1918 10.0.0.0/8. For public IPs, however, matching objects or groups are less likely to be defined in the configuration. If Policy Optimizer encounters a wide variety of public IPs and can't suggest a small set of public subnets, it defaults to recommending all public IPs, represented by negation of RFC-1918, where the three standard private subnets are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

   After optimizing a security rule, Policy Optimizer will not reselect it for further optimization for the next 90 days. This prevents redundant recommendations on the same traffic, which may no longer be applicable after implementing other recommended rules. Policy Optimizer waits 90 days because the 90 days period corresponds to the maximum look back period for log analysis.
4. Push Config to send the configuration updates and start enforcing the optimized rules.

5. Monitor the original rule until you’re confident that you don't need it.

   The original, overly permissive rules remain in your Security policy; it’s listed below the optimized rules in your rulebase and is tagged so you can easily identify it. The tag name appends _original to the rule name (for example, security-rule-name_original).

Manually Select a Rule for Optimization

You can add the predefined Enable-AIOps-Optimization tag to a rule to optimize it if it wasn't automatically selected by Strata Cloud Manager. Consider the scenario where a rule's source, destination, and application fields may still be more permissive than necessary. In this case, adding the Enable-AIOps-Optimization tag prompts Policy Optimizer to attempt further optimization of these fields. Or if the rules are not automatically selected if the zone fields are any, adding the tag could help to get recommendations on these fields as well.

Remove a Rule from Optimization

Move a rule to the Removed from Optimization list, and Policy Optimizer won’t optimize it. The rule settings remain as is.

Make sure to Push Config after moving a rule to the exclusion list; after pushing the configuration, it can take up to 24 hours for the rule to display on the list. You can always choose to add the rule back to the optimization list later.

Under Optimization Failed, you can also view the rules that failed optimization and check the reason for failure.

Track Optimization Results

Policy Optimizer shows a history of the security rules you have optimized. Historical data includes the optimization results: compare the original rule’s traffic coverage against optimized rules. You can also view how many days have passed since you accepted a rule for optimization.

If an original rule (a rule you optimized) gets no hits, Policy Optimizer removes it from the Policy Optimizer history and is classified instead as a zero-hit policy rule.