Security Policy Best Practices
    : Policy Optimizer Best Practices
    Focus
    Download PDF
    Focus
    1. Home
    2. Best Practices
    3. Security Policy Best Practices
    4. Security Policy Best Practices
    5. Deploy Security Policy Best Practices
    6. Policy Optimizer Best Practices
    Download PDF

    Security Policy Best Practices

    Policy Optimizer Best Practices

    Table of Contents

    Policy Optimizer Best Practices

    Best practices for analyzing and optimizing Security policy by eliminating unused rules and unused applications and converting port-based rules to application-based rules.
    Policy Optimizer helps you convert port-based Security Policy rules to application-based rules and transition to least privilege access policy rules:
    • Discover and convert port-based rules (application is any instead of a specific application) to application-based rules that follow the principle of least privilege access (PoliciesSecurityPolicy OptimizerRules Without App Controls).
    • Discover and remove unused applications from over-provisioned rules (PoliciesSecurityPolicy OptimizerUnused Apps).
    • Discover and eliminate rules that you don’t use and understand policy rule usage (PoliciesSecurityPolicy OptimizerRule Usage).
    • Discover new applications that match application filters and application groups used in Security policy rules. Evaluate new applications and whether you want to allow or block them (PoliciesSecurityPolicy OptimizerNew App Viewer).
      If you have a SaaS Security Inline subscription and use the App-ID Cloud Engine (ACE), use Policy Optimizer to integrate ACE App-IDs into your Security policy rulebase.
    • Discover Security policy rules that don’t have a Log Forwarding profile attached and add Log Forwarding profiles to those rules (PoliciesSecurityPolicy OptimizerLog Forwarding for Security Services).
    Policy Optimizer is available in PAN-OS 9.0 and later for Panorama and PAN-OS firewalls (firewalls can be on PAN-OS 8.1 if Panorama runs PAN-OS 9.0 or later). Policy Optimizer is available for Cloud Managed Prisma Access and Panorama Managed Prisma Access in PAN-OS 10.2.4 or later with Cloud Service Plugin 5.0 or later.
    Cortex Data Lake compatibility requires Panorama running PAN-OS 10.0.3 or later with Cloud Services plugin 2.0 Innovation or later.
    Policy Optimizer best practices covers:
    • How to Use Policy Optimizer—Major use cases, how to add applications to Security policy rules, sorting and filtering rules, and using application filters and application groups.
    • Policy Optimizer Rulebase Workflows—How to plan a transition to application-based rules, convert port-based rules to application-based rules, eliminate unused rules, and remove unused applications to tighten the rulebase.
    Decrypt all the traffic that local regulations, compliance, business requirements, and privacy considerations allow as soon as you can to provide more accurate application information and gain visibility into applications you control with Policy Optimizer. Without decryption, the firewall can often identify parent applications but usually can’t identify functional applications. For example, the firewall sees “facebook”, but not facebook-post, facebook-download, facebook-file-sharing, etc. You must decrypt traffic to gain visibility into and control of functional applications. For SSL Forward Proxy (outbound) decryption, implement User-ID and URL Filtering first so you can target decryption effectively.

    How to Use Policy Optimizer

    This section describes the major Policy Optimizer use cases and how to use the tool. Policy Optimizer Rulebase Workflows describes workflows.
    Policy Optimizer use cases include:
    • Migration from port-based application-based rules—View layer 7 applications that match each port-based rule, select the applications you want to allow, and convert each rule to one or more application-based rules.
    • New deployments—Discover applications on your network and transition to application-based policy over time.
    • Mature deployments—Examine your rulebase, convert broad rules based on application filters to tight rules based on application groups that allow only the applications you sanction, and eliminate unused rules and applications.
    • DevOps—Understand new or modified applications in your test environment. Work out how to handle them in Security policy rules before making changes in your production environment. Test the new and modified rules before you apply them in a production environment.
    1. Work with the appropriate people to understand the sanctioned applications you want to allow on your network for business purposes and the tolerated applications you want to allow for employees.
      Be aware of which applications are business-critical. Be aware of which applications are only used periodically for quarterly, annual, or other events, and evaluate relevant rules long enough to see the activity of these applications. Knowing the business logic for allowing applications helps you understand how to construct Security policy. To better understand applications, look up content-delivered App-IDs in applipedia or in ObjectsApplications on the firewall or Panorama.
    2. Learn how to sort, filter, and examine Policy Optimizer information and statistics using different metrics for different purposes.
      Policy Optimizer statistics aren’t reported in real time. It takes about an hour or more, depending on application traffic volume and rulebase size, to update the application list. After you add an application to a rule, wait at least an hour before checking Traffic logs for the application’s information. If you don’t see the information, wait a while and check again.
      Policy Optimizer ignores traffic from rules that only Log at Session Start to avoid counting transient applications. (For rules that also Log at Session End, Policy Optimizer picks up the rules’ statistics.)
    3. Understand how to use application filters and application groups in Security policy.
      Use application filters in Security policy rules to discover applications on your network. Then convert those rules from application filters to application groups so you can specify the exact applications to allow.
      • Use application groups as much as possible to simplify and tighten Security policy rules and reduce the size of the rulebase.
        Application groups are user-defined sets of specific applications that you want to control in one rule with similar security treatment. Add applications to rules using application groups (the linked topic focuses on ACE applications but applies to all applications) to control multiple applications with one rule instead of creating a separate rule for each application. Reuse application groups in different rules to give different users, sources, and destinations different access to applications. Reusing groups automates adding applications to multiple rules (when you make any change to an application group, the change is reflected in every rule that includes the application group).
      • Use application filters to:
        • Discover applications on your network.
        • Future-proof rules by handling new applications automatically when they match a filter. This is useful both in the application discovery phase in migrations and new deployments, and in mature environments.
          For example, create an allow rule with an application filter based on the Palo Alto Networks tag. This ensures that you allow all current Palo Alto Networks applications and all future Palo Alto Networks applications.
          Another example is creating a rule that filters for new content-delivered App-IDs to safely handle them until you can examine them more closely.
        • In mature rulebases, add applications to rules using application filters to block undesirable types of applications. Use application groups to purposefully allow traffic (the linked topic focuses on ACE applications but applies to all applications).
        Application filters are dynamic sets of applications. Applications match application filters based on attributes that you define, such as category, subcategory, risk, tags (pre-defined tags or custom tags), and characteristics. The firewall automatically adds new applications to a filter when they match the filter criteria. Security policy rules with an application filter automatically control new applications that match the filter.
        Application filters are looser controls than application groups. You control exactly which applications are in an application group. The attributes you define control the applications in an application filter, which can lead to allowing more applications than you need to allow. That’s why filters are best for discovering traffic and for blocking application subcategories of traffic. Reuse application filters in different rules to give different users, sources, and destinations different access to applications.
      Use application groups and application filters as much as you can instead of adding individual applications to rules. Beginning with PAN-OS 10.1, you can add applications to application groups and filters directly from Policy Optimizer, which is a best practice because it gives you visibility into all of the applications that a rule sees.
      Prior to PAN-OS 10.1, add applications to groups and filters using ObjectsApplication Groups and ObjectsApplication Filters.
    4. Decide which applications to add to a rule based on the purpose of the rule. The rule’s purpose helps determine who needs access to the applications and how (source, destination, inspection, logging) to grant access.
    5. Reuse application filter and application group objects in policy to give different user groups different levels of access to those applications and/or treat different source and destination combinations differently.
      User-ID is integral to creating best practices Security policy based on the principle of least privilege access. Without User-ID, you can’t specify who can use applications.
      Reusing application group and application filter objects reduces rulebase bloat by simplifying the rulebase.

    Policy Optimizer Rulebase Workflows

    This section describes transitioning from port-based rules to application-based rules and workflows for the Policy Optimizer tool. How to Use Policy Optimizer describes major use cases and how to use the tool.
    The end goal is to lock down the rules so that they allow only sanctioned applications and applications that you tolerate for employee use. In conjunction with that, lock down the users who have legitimate business reasons to access different applications. Use Traffic logs and the ACC to help you narrow the scope of rules to specific users to avoid over-provisioning user access. Work with application owners and other groups to understand who has business reasons for accessing applications.
    1. Plan a phased transition from port-based to application-based rules and understand key transition concepts and methods.
      Migrations and new deployments planning and methodology:
      • For migrations from port-based to application-based rules, start with your port-based Security policy rulebase. For new deployments and migrations, create rules based on application filters to gain visibility into different types of applications and add a catch-all rule at the bottom of the rulebase so you don’t accidentally block mission-critical applications. Apply best practices Threat Prevention profiles (both directions) and URL Filtering profiles (outbound traffic) to these rules. As applications match the catch-all rules, follow the advice in Step 2 to prioritize which rules to start converting and refining first, and how long to observe rules with different types of applications before transitioning them to application-based rules.
        Policy Optimizer shows you the specific layer 7 applications (App-IDs) that match each port-based rule.
      • Run best practice assessment reports directly in AIOps to set a baseline so that you understand your current best practices state. Run periodic reports to measure progress. Progress means fewer port-based rules, fewer unused rules, and fewer rules with unused applications over time.
      Existing deployments planning and methodology:
      • If the deployment consists of port-based rules or mostly of port-based rules, follow the previous advice for migrating to application-based policy.
      • If the deployment consists of mostly application-based rules, place a catch-all rule at the bottom of the Security policy rulebase to discover and gain visibility into applications that don’t match other rules, with strict Security profiles to stop malicious traffic. Follow the prioritzation advice in Step 2 to tighten the rules.
      After you move applications from port-based rules to application-based rules, select the port-based rules in Policy Optimizer and Reset Rule Hit Counter. This resets the Days with no new apps counter so you can see when more new applications match the original port-based rules and evaluate whether you want to allow or block them.
      After you refine a rule, wait until Days with no new apps reaches at least seven days before you revisit the rule to continue refining it. When the catch-all rules and port-based rules no longer see applications that you want to allow, disable or delete them. Be aware of applications your enterprise uses only for periodic events before you disable or delete a rule.
    2. Prioritize and convert port-based Security policy rules (rules with the application set to any) to layer 7 application-based rules.
      Prioritize which rules to convert from port-based rules to application-based rules at what phase of the transition. These techniques are valid for migrations and new deployments, and for existing application-based deployments where you need to tighten your rulebase:
      1. In new and existing deployments, block known-malicious and risky traffic immediately.
      2. Implement catch-all rules based on application filters.
      3. Convert simple rules with well-known-applications after one week. For example, rules that control port 21 (FTP), port 53 (DNS), port 22 (SSH) are good candidates for quick conversion. The fewer and more well-known the applications in a port-based rule, the more confident you can be in converting it to an application-based rule.
      4. After 30 days, convert the most stable rules. Rules that see no new applications over a 30-day period and that control relatively few applications are good candidates.
      5. After at least 30 days, begin to convert internet access rules (ssl, web-browsing) and rules that see the most traffic.
      6. After a time period appropriate for the applications seen on the rule, convert rules with few Apps Seen.
      7. As you convert rules, review each rule when Days with no new Apps reaches at least seven days (longer for complex rules or rules with many applications) and handle and new applications as needed.
      Cloning rules is the safest way to transition from port-based rules to application-based rules. Cloning preserves the original port-based rule and places the cloned rule directly above the original rule. This enables you to carve out specific, application-based rules from the original rule without risking application availability, as shown in this cloning use case example for migrating your web browsing and ssl traffic to application-based rules. Applications that don’t match cloned rules continue to match the original port-based rule. When the original rule stops seeing applications that you want on your network for an appropriate period of time, you can safely disable or delete the original rule.
      Use application groups and application filters appropriately as you convert rules.
    3. As you examine rules, use application filters to block application types that you know you don’t want on your network. Block traffic based on subcategories, tags, and characteristics. Use application filters to make exceptions to block rules. Don’t use risk as blocking filter criteria, use risk to determine how to inspect, log, and control the traffic appropriately.
      In addition to the recommended block rules to stop known-malicious traffic, review your rules regularly and block other traffic that you know you don’t want:
      1. Identify application types that you don’t want on your network and create application filters that match them. Create block rules based on those application filters and place them in front of any catch-all rules (or clone the rule from an existing rule and place the cloned rule directly above the original rule in the rulebase).
      2. Determine if there are specific applications within the blocked application types that you want to allow on your network. Clone the block rule, change the Action to Allow, and remove all applications except the applications you want to allow. Place the allow rule directly above the block rule to create exceptions to the block rule.
      3. Monitor the block rule to see if you want to allow any other blocked applications. If you created an allow rule for exceptions, add applications you want to allow to that rule. Otherwise, create a new allow rule for the applications and place it directly above the block rule in the rulebase.
      For example, file sharing applications can be particularly risky. Decrypt the traffic, and in the Security policy rule, allow only the specific file sharing applications you use for business purposes for only the necessary users and inspect and log the traffic. In the next rule in the rulebase, use an application filter based on the file-sharing subcategory to block all file sharing applications that you don’t explicitly, purposefully allow.
    4. Remove unused applications from over-provisioned rules.
      Understand an application’s purpose before you remove it from a rule.
      • Compare Apps Used to Apps Allowed. If the rule allows more applications than the rule uses, examine the unused applications and determine whether you can remove them.
      • Be aware of applications used only for quarterly, yearly, or other periodic events. Make sure you capture a long enough history of the rule to see those applications. Also take into account applications that are active in your test environment and that have been added to your production environment in anticipation of sanctioning the application.
    5. Remove unused rules from the Security policy rulebase.
      Unused rules clutter and complicate the rulebase. Rule Usage shows you information about unused rules over different time periods. Evaluate the applications in the rules to see if you need them even though they haven’t been used. Before you remove unused rules, take into account:
      • Block rules with no hits—Don’t disable or delete these rules. For example, a block rule using a threat EDL receives no hits. That’s good, but you want to continue to block in case malicious traffic tries to access your network.
      • Temporary rules—For example, rules for contractors or auditors. Instead of deleting those rules, if there’s a regular access time, configure a schedule to control when the rule is in effect. If access is intermittent, disable the rules and enable them when needed.
      • Disabled policy rules—Apply a tag with the date the rules were disabled. If the rules aren’t used within a particular time period, for example, more than one year, the rule is a candidate for deletion. Add a Description to indicate why the rule is disabled and why or when it may need to be enabled, for example, for auditor or contractor access.
      • Periodically-used applications—Some applications are only used for quarterly, yearly, or other periodic events. Capture a long enough history of rules that control these types of applications to be sure the applications are no longer in use.
    6. Ensure that each rule has an appropriate Log Forwarding profile attached.
      Identify rules without Log Forwarding profiles and add profiles to them (PoliciesSecurityPolicy OptimizerLog Forwarding for Security Services).
    7. Convert broad rules based on application filters into narrow rules based on application groups.
      Use Rule Usage statistics to understand how rules are used and use Policy Optimizer to add applications to application groups (PAN-OS 10.1 and later; for PAN-OS 10.0 and earlier, add applications to application groups in ObjectsApplication Groups) and create tighter rules.
      The end goal is to allow only the applications you sanction instead of allowing a broader range of applications that match an application filter. Use application filters to discover applications on your network and block broad subcategories of applications, and use application groups to specify the exact applications you want to allow. To convert application filter based rules into application group based rules using Policy Optimizer:
      • Examine the applications that match rules based on application filters and decide which applications you want to allow.
      • For each rule based on an application filter, select the applications to allow and add the applications to an application group in a cloned or existing rule.
      • After you move applications from rules based on application filters to rules based on application groups, select those rules in Policy Optimizer and Reset Rule Hit Counter. This resets the Days with no new apps counter so you can see when new applications match those application filter based rules.
      • Monitor rules based on application filters until the Days with no new apps counter reaches a threshold that indicates a rule is no longer seeing new applications. The threshold depends on your environment and the types of applications the application filter matches. Take into account applications used only at certain periods, such as quarterly or annual events, and leave the filter in place long enough to see those applications so you can add them to the appropriate application groups. If the application filter rule matches no applications that you want on your network, disable or delete the rule, depending on your enterprise’s policy.
    8. Review and update Security policy rules as new applications enter your environment.
      Review new App-IDs regularly in New App Viewer. Add applications to existing and new application groups or to add applications directly to existing Security policy rules. Continue to convert application filters to application groups.

    © 2024 Palo Alto Networks, Inc. All rights reserved.