Guidelines and Limitations for Policy Optimizer

Optimize a Rule

1. Go to ConfigurationPosturePolicy Optimizer.
2. At the top of the Policy Optimizer page, select Cloud Manager for Strata Cloud Manager managed deployments or a Panorama instance for Panorama managed deployments containing the policy rules that you need to optimize.

   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.

   If no rules have been optimized by Policy Optimizer, a banner will appear to indicate this.

   For rules managed through Panorama, the Location field indicates the specific device group in the Panorama configuration. Note that the Modified and Creation dates will be empty for these rules.
3. 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. The Optimize Security Policy Rule page includes general breadcrumb navigation. For Panorama devices, the page also indicates the specific device group for which you are optimizing rules. The breadcrumb shows the manager for which the rules and the associated recommendations are shown.

   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.
4. Before you accept recommendations, you can make changes to the optimized rules.

   • Edit the name of the optimized rules.
   • Delete individual applications, application groups, or both in the Applications sidecar.
   • 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 to restore the rules to their original recommended state. This action undoes all edits. You can revert the disabled rules as long as they haven’t been accepted yet.
   • 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 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 checkbox.
   • 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 cannot 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.
5. 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.

   • For Strata Cloud Manager-managed configurations, 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. 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.
     Push Config to send the configuration updates and start enforcing the optimized rules.

   • For Panorama-managed configurations, after you Accept, you will see the Optimization Summary window. You need to Update Panorama Rulebase to push the configurations to the candidate Panorama from Strata Cloud Manager. To commit the configuration to Panorama, you need to log in to it and commit the changes. See Preview, Validate, or Commit Configuration Changes.

   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. The Optimization History table in the Policy Optimizer page includes the Status column for Panorama managed deployments. Here are the statuses:

   • Updated in Candidate Config - Pending commit
   • Success - Updated in Candidate Configuration
   • Error

   If an error occurs, the status will show "Error," accompanied by a tooltip that provides a specific error message, such as Failed to update panorama config. Importantly, when an error occurs, the rule is automatically returned to the optimization queue. For more details on troubleshooting configuration errors, see Preview, Validate, or Commit Configuration Changes.

   After optimizing a security rule, Policy Optimizer will not reselect it for further optimization for the next 15 days. This prevents redundant recommendations on the same traffic, which may no longer be applicable after implementing other recommended rules.
6. 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).

User to Application Optimization

Source User Optimization

Policy Optimizer analyzes traffic logs to detect and recommend specific users or user groups for the Source User field. You can review these recommendations and delete any users or user groups before accepting the recommended rules.

Policy Optimizer follows these rules when generating source user recommendations:

• If Policy Optimizer can’t identify a relevant set of users, groups, or both within the defined threshold (10 by default), it recommends the predefined keyword known-user for known users.
• If the traffic logs don’t contain the source user data, Policy Optimizer recommends unknown for the Source User field.
  If the original rule specified certain users, Policy Optimizer makes sure that the new optimized rule will not allow additional users than the original rule. It will only refine the rule to be more specific.
• If there are too many individual users in the source user field, Policy Optimizer may recommend known-users to simplify the rule while maintaining least-privilege access.
• A minimum threshold of 75% is required to associate individual users with a user group. This means that at least 75% of the user group's resolved user IDs must be present in the log data for the user group to be considered in the recommendations.

You can click Users to view the list of users in a side car panel.

Policy Optimizer provides contextual logs to offer insights into the traffic triggering the rule with an unknown user. For recommendations where the source user is unknown, click Unknown User to open Log Viewer.

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.