Security Policy Best Practices

This section covers 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 rules define traffic matching criteria, including applications, users, devices, source and destination, URLs, and services (ports). Combining matching criteria adds more granular context to a rule, narrows the scope of the rule, and reduces the attack surface. The matching criteria enable you to define the exact traffic you want to control with the rule and to adhere to Zero Trust Network Access (ZTNA) principles.

Security policy rules also define actions to take on traffic that matches a rule’s criteria, including whether to allow or deny the traffic, logging and log forwarding, threat inspection, and scheduling.

Create Security policy rules that are as specific as possible to apply the principle of least privilege access and to segment the network.

Sources and Destinations—Best practices for applying the principle of least privilege access to lock down traffic sources and destinations.

Policy Actions and Other Settings—Best practices for how to allow or deny traffic and for applying QoS.

Logging and Log Forwarding—Best practices for logging traffic and forwarding logs for long-term storage and analysis.

To create effective Security policy, it helps to understand critical concepts about what Security policy rules do, how they work in the Security policy rulebase, how traffic matches rules, and best practices for rule construction.

Decrypt all the traffic that local regulations, compliance, business requirements, and privacy considerations allow. For SSL Forward Proxy (outbound) decryption, implement User-ID and URL Filtering first so you can target decryption effectively. Decrypting traffic provides visibility so the firewall can identify functional applications (for example, not just facebook but facebook-post, facebook-download, facebook-file-sharing, etc.), identify websites, and apply threat profiles to inspect and prevent threats in the traffic. Decrypting traffic enables you to get the most protection and prevention from your threat subscriptions.

—Security policy on Palo Alto Networks firewalls is based on explicitly allowing traffic in policy rules and denying all traffic that you don’t explicitly allow (allow list). Traffic that you don’t explicitly allow is implicitly denied. The goal is to allow only the applications, users, and devices that you want on your network and let the firewall automatically block what you don’t want.

As you move toward allow list based Security policy, use block rules to prevent access to risky IP addresses, websites, and applications. Create and test block rules based on the pre-defined External Dynamic Lists (EDLs) to block bulletproof IP addresses, high-risk IP addresses, and known malicious IP addresses lurking within otherwise benign application categories and to prevent authenticating to a malicious URL or domain. Use Advanced URL Filtering to block access to risky websites.

Be particularly careful with file sharing applications because bad actors can use them to exfiltrate data. Block most file sharing applications. For file sharing applications that you need for business purposes, allow access only to users who need those applications for business purposes.

For the tightest security, allow only applications used for business purposes. However, most enterprises need to allow some non-business applications for employees (tolerated applications). Consider which tolerated applications to allow and ask yourself if those applications pose any threat to the organization, such as the ability to upload or download data. Decrypt and inspect as much traffic as you can for threats.

Security policy rules are specific. If traffic doesn't match every criteria specified in a Security policy rule, the traffic does not match the rule. For example, if a rule specifies a particular user, an application, and a source and destination, the traffic must match all of those criteria to match the rule. If the user, source, and destination match but the application does not match, then the traffic doesn’t match the rule.

Security policy rules segment your network by defining who has access to which applications and infrastructure. Rules segment the network by defining the source, destination, user, device, service, and URL.

Security policy rules apply all attached Threat Prevention profiles to traffic that matches the rules.

Security policy rules are in an ordered rulebase (you choose the order of the rules). Firewalls compare traffic to Security policy rules starting with the first rule in the Security policy rulebase and move through to the last rule in the rulebase. When traffic matches a rule’s criteria, the firewall takes the rule’s Action on the traffic, and doesn't compare the traffic to any other rules. If no rule matches the traffic, the firewall drops the traffic (implicit deny).

Place more specific, granular Security policy rules above general rules in the rulebase to avoid shadowing a rule. Shadowing is when a broad rule that includes the same matching criteria as a more specific rule is placed higher in the rulebase than the specific rule. In that case, traffic intended to match the specific rule instead matches the general rule first.

If traffic matches no other rules, two default Security policy rules at the bottom of the rulebase automatically drop all traffic between different zones (

). You can modify the interzone-default and intrazone-default rules to log traffic, apply threat inspection, etc. If you add a rule that denies all traffic earlier in the rulebase (local firewall rules or Panorama pre- and post-rules), no traffic matches the default rules.

Apply the principle of least privilege access to Security policy rule construction (be granular, precise):

Control which administrators have access to administer which portions of which firewall and Panorama devices. Follow best practices for securing administrative access.

Identify all users (no unknown users should be on your network), identify the applications you want to allow on your network, and know your infrastructure (resources that users and applications access). Map who needs access to which applications and resources for business purposes so that your Security policy rules allow no unnecessary access. Allow access to business resources and sanctioned applications only to users who need access for business purposes, and allow only the minimum required access.

In most cases, use allow rules instead of block rules—it’s more accurate and easier to define what you want to allow on your network and implicitly deny the rest than it is to explicitly block the ever-increasing number of applications that you don’t want on your network.

Optimize the rulebase to edit rules with unused applications and to remove or disable rules that aren’t used.

The Name, Description, Audit Comments, and Tags fields make it easier to manage and navigate your Security policy rulebase and to understand what each rule does. They also help new and experienced administrators understand when to add a new application, user, or user group to an existing rule and when to create a new rule.

Develop a standard naming convention which uses terms that make it easy to search the rulebase. Names that clearly show administrators what each rule does make it easier to understand the traffic that each rule controls and makes searching for any particular rule easier and more intuitive.

—Describes the purpose of the rule so that anyone examining the rulebase can understand why the rule was created and the intended result.

on individual firewalls). For existing rules without a description, add one next time you edit the rule.

—High-level descriptors to describe flow-based components, application-based policy, internal services, particular user groups—whatever makes sense for your business.

Tags organize policies into groups, which enables you to filter and search for policies based on tags.

and apply it to all disabled rules, you can filter the rulebase and see all disabled rules based on that tag. Using the same tag, you can search the rulebase for rules that are labeled

on individual firewalls). For existing rules, the commit fails if you don’t add a tag and description the next time you edit the rule.

—Tracks changes to rules and why changes were made so that you have a history of rule changes and rationales for the changes. This is especially useful to document rules that are only used in case of disaster recovery or on a limited basis.

on individual firewalls) and specify an audit comment format. For existing rules without audit comments, you must add them next time you edit the rule.

Controlling traffic sources and destinations is about following the principle of least privilege access. Create Security policy rules that specify the exact source and destination for application traffic that you want to match the rule. Allowing traffic on the rule from sources and destinations that applications don’t require for business purposes increases the attack surface, which increases risk. Strictly limiting sources and destinations to those required for business purposes reduces the attack surfaces and decreases risk.

Sources—Zones, addresses, users, and devices, 5G Security, subscribers, equipment, and network slice.

As much as possible, use address group and user group objects instead of individual addresses and users to reduce the number of source and destination objects. This simplifies policy and makes it easier to understand. Limit the total number of source and destination objects for rulebase clarity.

In PAN-OS, specify source and destination zones as narrowly as possible to prevent unnecessary access to data and applications.

Dedicating zones for particular purposes, such as a zone for all web servers, makes it easier to create granular policy because all of the servers in the zone usually require the same security policy.

uses three zones: trust, untrust, and clientless VPN, which is mapped to the trust zone by default. In many third-party SD-WAN integrations, in the Log Viewer, the source zone uses the name of the remote network.

Specify source and destination addresses as narrowly as possible to prevent unnecessary access to data and applications. Use address groups instead of individual addresses as much as possible to simplify policy. If the rule is for all of the devices in a zone, for inbound traffic specify the destination address as

Use FQDN address objects to reference internal systems so that when system IP addresses change, the change doesn’t affect policy.

Use Dynamic Address Groups (DAGs) in policy to adapt automatically to changes in server roles or in security posture based on log events and auto-tagging. Think about how to group servers and develop a tagging strategy that makes sense for your business.

When a specified log event occurs, the firewall moves IP addresses from one DAG to another DAG based on auto-tagging. DAGs are updated automatically and don’t require a commit action. This enables you to take automated security actions such as moving a potentially infected server or endpoint from a DAG in a policy rule that allows access to critical resources to a DAG in a policy rule that blocks that access (quarantining a device).

In data center environments with automation, use DAGs to control access for VMs as the data center spins up and spins down virtualized servers. Dynamically register tags using the native XML API or the VM Monitoring agent on the firewall.

In data center environments, segmentation combined with automation might make it difficult to manage individual IP addresses. As a last resort if the environment is too difficult to manage, use subnets, but this is a less secure method.

If compliance, business policy, or other reasons require you to block geographic regions, specify the region or regions as the address. (For inbound traffic, specify the geographical region as the source and

Specify source users with User-ID so that Security policy is valid for both on-premises and remote access. Consistent user identification is critical to ensure consistent policy regardless of user location and method of connectivity.

This viewpoint groups users by resources they need to access and applications they need to use so you can create logical groups and apply policy to them.

Have the network security team work with the team that controls user groups to help ensure that the groupings make sense for security controls.

Specify individual users in policy only when you can’t use groups. For example, your CEO and few other C-suite executives might require various access privileges that other users and groups should not have.

CIE provides authentication via integration with Identity Providers such as Okta, Azure AD, and many others.

GlobalProtect is the User-ID mapping source with the most accurate and comprehensive user information and greatest accuracy (there are also many other possible User-ID mapping sources).

Use Dynamic User Groups (DUGs) in policy to automatically remediate anomalous user behavior and malicious activity based on log events and auto-tagging. DUGs work similarly to DAGs. Think about what activities warrant quarantining or restricted access and develop a tagging strategy that makes sense for your business.

Also use DUGs to allow periodic access to user groups. For example, a DUG can allow access for quarterly auditors (as defined by a user group for auditors) during audits and block access at all other times.

In Security policy rule configuration, in addition to specifying particular users and groups, you can specify whether the rule applies to

for rules that apply to all network users, for example, access to basic services such as DNS, NTP, OCSP, etc.

Remote Access VPN with Pre-Logon is specific to GlobalProtect users. It establishes a VPN tunnel before the user logs in to the device to authenticate the endpoint and enable access to specific services such as DHCP, DNS, etc., and requires installing machine certificates on each endpoint. Policy rules that allow pre-logon user access must allow access only to services for machine authentication and necessary network services. Deny all other access for pre-logon users.

The overarching principle is least privilege access. Allow access only to users and groups that require access to applications and resources for business purposes.

In Security policy rules that govern IoT devices (IoT Security requires a subscription), specify IoT devices using Device-ID (PAN-OS 10.0 and later).

Device objects define the Device-IDs of IoT devices and identify source devices in the same way User-ID identifies source users. Device objects have six metrics to use as match criteria. A device must match all of the configured metrics to match a Device-ID. In most cases, defining one or two metrics is sufficient. The more metrics you define, the greater the chances that the filter is too specific and won’t match the devices you want to match. Understand what information devices send to the firewall to know which metrics to configure to define the device object (not all devices transmit all metrics). The following operational commands show the information that IoT devices send to the firewall:

By default, an implicit deny rule at the bottom of the Security policy rulebase blocks applications that you don’t explicitly allow in a Security policy rule. To enforce least privilege access, refine Security policy rules until they specify only the exact applications you want to allow for business purposes (sanctioned applications) and for your employees (tolerated applications). Application-based rules provide granular control of who uses each functional application and how they use it, so you can create precise Security policy rules as you move toward a Zero Trust Network Access environment. Port-based rules allow any application on the open port; avoid them.

You must enable decryption for the firewall to see the functional application instead of just the “-base” application. Seeing the functional application enables you to control applications granularly. For example, instead of seeing just the container application “facebook”, the firewall can see “facebook-posting”, “facebook-downloading”, “facebook-file-sharing”, etc. This enables you to configure Security policy based on least privilege access; instead of giving all employees access to all facebook functional applications, you can restrict or block access to specific functional applications for appropriate users.

When you add a container application to a rule, all of its functional applications are added to the rule implicitly. Specify the exact functional applications you want to allow to gain more granular control of the applications you allow and who you allow to use them.

How you apply best practices advice for applications depends on whether your environment is new, existing, or a migration. Many of the recommendations reflect the final best practices state. In some cases, we provide transition advice or advice about different environments. However, every environment is unique. The goal is to understand what applications traverse your network, what sanctioned and tolerated applications you want to traverse your network, and to use that information to transition safely to a Security policy rulebase that allows only the applications you sanction for business purposes and tolerate for employee access.

Security Policy Rulebase Best Practices covers where to position rules in the Security policy rulebase.