Deploy Security Policy Best Practices

Security Policy Rule Best Practices—Focuses on every aspect of Security policy rule construction, from who can access what applications and resources in which way to applying threat profiles that help safeguard traffic from malware.
Security Policy Rulebase Best Practices—Focuses on the sequence of Security policy rules in the rulebase and how that affects the traffic you allow and block.
Policy Optimizer Best Practices—Focuses on using Policy Optimizer to tighten and maintain the rulebase.
App-ID Cloud Engine Best Practices—Focuses on how to use cloud App-IDs in Security policy and how to automate adding new cloud App-IDs to the rulebase. (The App-ID Cloud Engine requires a SaaS Security Inline subscription.)
Policy Recommendation Best Practices—Focuses on SaaS Policy Recommendation and IoT Policy Recommendation. (SaaS Policy Recommendation requires a SaaS Security Inline subscription and IoT Policy Recommendation requires an IoT Security subscription.)

The principle of least privilege access; limit access to only the right people using only the right applications, from only the right sources to the right destinations.
Follow Decryption Best Practices. Decrypt as much traffic as your business considerations, local and privacy regulations, and legal compliance allow to gain maximum visibility into traffic so that you can inspect and control it. For SSL Forward Proxy (outbound) decryption, implement User-ID and URL Filtering first so you can target decryption effectively.
For outbound decryption, get an Advanced URL Filtering license so that when decryption exposes a malicious website, URL Filtering can block access to it.
Some traffic cannot be decrypted for technical reasons due to pinned certificates, client authentication, embedded certificates in IoT devices, etc.
Inspect all traffic in both directions for threats. Trust nothing implicitly.
Automate as much as possible to help ensure that Security policy stays up to date using dynamic address groups (DAGs), external dynamic lists (EDLs), and VM monitoring features.
Use auto-tagging to automate security actions for users and devices based on log events. Auto-tagging enables you to automate the actions to take when a log event happens, for example, quarantining a potentially infected device or forcing a user to use MFA authentication.
Avoid configuration bloat:
Reuse objects such as Security profiles and profile groups, tags, application groups, application filters, user groups, and address groups. On Panorama, use shared objects to avoid configuring the same objects for multiple device groups.
Before you add a new policy rule to the rulebase, check existing rules to see if you can add new applications, users, or devices to existing rules instead of creating multiple similar rules.
See if an existing rule is the same except for one of the following objects: source zone, destination zone, source IP address, destination IP address, application, service port, or user. If only one of those objects is different, add the new object to the existing rule instead of creating a new rule.
For example, you want to allow a new accounting application. When you look at the existing rulebase, you find a rule for a different accounting application that allows access from the same source to the same destination, for the same user groups, using the application’s default port. Instead of writing a new rule for the new application, simply add the new application to the existing rule.
This method also works well for consolidating existing rules.
For outbound traffic, create one rule based on URL categories for multiple applications that require the same security treatment. For example, to allow all low-risk financial services traffic (assuming you want to inspect and log the traffic the same way), create an allow rule that specifies both the
financial-services
and
low-risk
URL categories.
Use Policy Optimizer to remove unused rules.
Use Panorama or Cloud Managed Prisma Access to manage firewall deployments so that you can use device groups to apply consistent Security policy to single or groups of firewalls.
Use pre-rules and post-rules appropriately:
Pre-rules—Firewalls evaluate pre-rules before locally-defined rules and post-rules. (Locally-defined rules on individual firewalls apply only to those firewalls.) Place policies that apply to all firewall deployments in the pre-rules, such as allowing DNS and other critical services and using the pre-defined threat EDLs to block known malicious and high-risk IP addresses.
Post-rules—Firewalls evaluate these rules after pre-rules and locally-defined rules.
In Panorama Security policy rules, use the
Target
tab to exclude specific firewalls or device group subsets from the rule (
Target to all but these specified devices
). This enables you to create one broad rule higher in the hierarchy instead of creating multiple similar rules lower in the hierarchy to make the exception.
Application Override policy is not the same as layer 7 Security policy. Don’t use it unless you must because Application Override removes many security controls that are inherent to the Palo Alto Networks platform. Application Override doesn’t enable you to inspect layer 7 traffic, use Security profiles to protect traffic against threats, or use App-ID, so it increases risk. In most cases, it’s better to create a Custom Application or use a custom service timeout than to use Application Override.
Review your existing rulebase. If you have Application Override rules for traffic other than SMB or SIP, convert the rule to an App-ID based rule so that you can decrypt and inspect the traffic at layer 7 and prevent threats. If the rule is for SMB or SIP traffic, ensure that it follows the principle of least privilege access and is as restrictive as possible.