Optimize a Rule

1. Go to ManageSecurity PosturePolicy Optimizer.

   Review overly permissive rules, and choose a rule to see the optimization recommendations. If there are multiple overly permissive rules, focus on optimizing the rules that are impacting the most traffic; this will give you the most significant gains toward strengthening your security posture.

2. Review the recommended, optimized rules.

   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.

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 are not accepting it, and it will not 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).
   • 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.

   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 will not 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.