How Policy Optimizer Generates Recommendations

Once a rule qualifies, Policy Optimizer analyzes its associated traffic logs and maps observed data to your existing configuration objects. It then generates one or more tightly scoped replacement rules. The following sections describe how each field is processed.

Source and Destination Zones

Policy Optimizer analyzes logs for the exact zones traversed by matching traffic, and recommended rules restrict access exclusively to those zones. For Prisma® Access environments, zones are mapped to standard trust or untrust models. For snippet rules, zone fields are preserved as-is because snippets are zone-agnostic by design and must remain valid across all locations where the snippet is attached.

Source and Destination Addresses

Address optimization replaces broad any rules with strict IP and network boundary definitions based on observed flows:

• Subnet up-leveling: Individual observed IP addresses are first consolidated into broader standard network subnets for a clean, manageable policy structure.
• Mapping to configuration objects: Consolidated networks are matched against your predefined address objects (such as ip-netmask and ip-range) and address groups. If a defined address group accurately covers the traffic, the group is recommended instead of individual objects to keep the rulebase concise.
• Standard IP ranges: Addresses that fall within RFC-1918 private subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or other special-use ranges are automatically recommended using standard subnets, even if no explicit address objects exist.
• Public IP traffic: For rules with a large number of global public IP addresses, Policy Optimizer recommends all public IPs using negation of the three standard RFC-1918 private subnets, ensuring that traffic to internal infrastructure remains restricted.

Source User

User-to-application optimization enforces identity-based security per rule when your Strata Cloud Manager tenant is integrated with Cloud Identity Engine (CIE). Policy Optimizer matches each traffic flow to defined individual users and user groups, and recommends the most specific set that covers the observed traffic:

• If the set of users exceeds the simplified tracking limit (10 by default), Policy Optimizer recommends the predefined keyword known-user, which enforces that only authenticated domain users have access and drops anonymous traffic.
• If traffic logs contain no associated user data for unauthenticated endpoints, Policy Optimizer recommends the predefined keyword unknown, allowing you to build a specific rule for unauthenticated device access.
• A minimum threshold of 75% is required to associate individual users with a user group—at least 75% of the user group's resolved user IDs must appear in the log data for the group to be recommended.
• Policy Optimizer does not recommend additional users beyond those already permitted by the original rule. Recommendations only refine the rule to be more specific.
• If CIE is unavailable, source user optimization is skipped and the original rule's Source User field is preserved unchanged.

Click Users in the recommendations panel to view the full list of users in a side panel. For recommendations where the source user is unknown, click Unknown User to open Log Viewer and review the associated traffic.

Applications

Replacing port-based rules with App-ID policies is central to the optimization. Policy Optimizer observes raw application signatures in traffic logs and builds granular application policies:

• Observed applications are consolidated and recommended as defined application groups, application filters, or predefined Applipedia containers where applicable.
• Policy Optimizer automatically detects and includes any underlying application dependencies required for the observed applications to function properly.
• Traffic involving unknown applications (such as unknown-tcp or unknown-udp) is categorized separately, generating isolated rules so you can investigate unidentified traffic patterns.

Service

The service field is evaluated in relation to the detected applications:

• If all detected applications used their standard protocol and ports, Policy Optimizer recommends setting the service field to application-default (if the original value was any). This ensures that applications cannot run on non-standard ports.
• If applications ran over non-standard ports, Policy Optimizer retains the original service object configurations to prevent breaking legacy application flows.

Tags

Policy Optimizer automatically applies tags to help you identify original and optimized rules in your Security policy:

• The original rule's name receives an _original suffix (for example, security-rule-name_original).
• Each recommended optimized rule receives a tag with a _derived suffix (for example, security-rule-name_derived).

Clustering and Rule Formulation

In complex environments, a single overly permissive rule may serve multiple distinct functions. For example, allowing specific users to access IT applications and different users to access HR applications. Instead of replacing the original rule with one large, combined rule, Policy Optimizer clusters observed traffic into distinct groups based on IP networks and application categories. This produces multiple specific, easy-to-read rules that together cover all necessary business traffic while closing broad security loopholes. As a safeguard, a recommended optimized rule never allows traffic that was not already permitted by the original rule.

Policy Optimizer Support for Snippet Rules

In addition to rules defined directly in folder or device containers, Policy Optimizer evaluates rules defined within snippets. Policy Optimizer now treats snippet rules as first-class optimization targets. When you select Strata Cloud Manager as the device scope, snippet rules appear alongside folder and container rules in the optimization grids. The Location column displays the snippet name to identify where each rule is defined. A snippet is a reusable configuration object that you can associate with multiple folders, devices, or deployments simultaneously. When you associate a snippet with a container location, Strata™ Cloud Manager applies its rules to all traffic handled by that location. Optimizing snippet rules ensures that security improvements apply consistently across every associated deployment.

You can manage recommendations for snippet rules using standard Policy Optimizer actions:

• Accept: Saves the optimized rules back to the snippet. Changes propagate automatically to every location where the snippet is attached.
• Merge: Combines related rules within the snippet to streamline your rulebase.
• Disable: Deactivates unused or redundant snippet rules across all associated containers.
• Revert: Restores original snippet rule settings when necessary.

Snippets are designed to be zone-agnostic so that their rules function correctly across locations with varying zone topologies. To maintain multi-location compatibility, Policy Optimizer preserves source and destination zone fields as any when generating recommendations for snippet rules.

Policy Optimizer narrows all other rule fields based on observed traffic, including:

• Applications
• Source IP addresses
• Destination IP addresses
• Source users

This selective narrowing produces recommendations you can apply once to the snippet and have take effect correctly across all associated deployments. Snippet rule optimization applies exclusively to Strata Cloud Manager.

Policy Optimizer for Panorama-Managed Configurations

Guidelines and Limitations for Policy Optimizer

Optimize a Rule

1. Select ConfigurationPosturePolicy Optimizer.
2. At the top of the page, select Cloud Manager for Strata Cloud Manager-managed deployments, or a Panorama instance for Panorama-managed deployments.

   The Ready for Optimization tab lists all overly permissive rules with available recommendations, sorted by traffic volume with the highest-hit rules first. When you select Strata Cloud Manager, snippet rules appear alongside folder rules; the Location column shows the snippet name for snippet rules and a folder or container name for all others.

   For Panorama-managed rules, the Location field shows the specific device group. The Modified and Creation dates are empty for Panorama rules.

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

3. Select a rule to view its optimization recommendations.

   You can see how much of the original rule's traffic each new rule covers and review the specific applications each rule enforces. View recommendations by Overall Traffic, Session Count, or Number of Unique Users. All recommended rules are prepended with optrule and appended with an integer.

4. Adjust the recommended rules before accepting.

   • Edit the name of any optimized rule.
   • Delete individual applications or application groups in the Applications sidecar.
   • Disable a recommended rule to exclude it from acceptance. The rule is removed from the recommendation list and is not added to the rulebase.
   • Revert to undo all local edits and restore the original recommendations. You can revert disabled rules as long as they have not been accepted yet.
   • Merge two or more similar recommended rules into a single rule. Negated and unnegated addresses cannot be merged.
   • Create source or destination address groups within recommendations to manage policies at scale. The address group retains the original configuration scope by default. Enable the checkbox to change it to the global scope.

5. Accept some or all recommendations.

   Click Accept All to accept all recommended rules as-is, or select individual rules to accept.

   • For Strata Cloud Manager-managed configurations: After accepting, click Update Rulebase. The optimized rules are added to your Security policy but do not enforce traffic yet. For snippet rules, Strata Cloud Manager saves the optimized rules back to the snippet directly, and the change propagates to all associated locations automatically. Click Push Config to start enforcing the optimized rules.

   • For Panorama-managed configurations: After accepting, the Optimization Summary window appears. Click Update Panorama Rulebase to push the configurations to the Panorama candidate config. Then log in to Panorama and commit the changes. See Preview, Validate, or Commit Configuration Changes.

   The Optimization History tab shows statuses for Panorama-managed rules:

   • Updated in Candidate Config—Pending commit.
   • Success—Updated in Candidate Configuration.
   • Error—The rule is automatically returned to the optimization queue. A tooltip provides the specific error message.

   After optimizing a security rule, Policy Optimizer does not reselect it for further optimization for the next 15 days. This prevents redundant recommendations on the same traffic after other optimized rules have been applied.
6. Monitor the original rule until you are confident you no longer need it.

   The original rule remains in your Security policy below the optimized rules, tagged with _original appended to its name (for example, security-rule-name_original). Each recommended rule carries a _derived tag for easy identification.

Remove a Rule from Optimization

Move a rule to the Removed from Optimization list, and Policy Optimizer does 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 add the rule back to the optimization list later.

Under Optimization Failed, you can 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 the optimized rules. You can also view how many days have passed since you accepted a rule for optimization.

If an original rule gets no hits, Policy Optimizer removes it from the optimization history and classifies it as a zero-hit policy rule instead.