Focus

Security Policy Best Practices

Security Policy Rule Best Practices

Table of Contents

Security Policy Rule Best Practices

Best practices for PAN-OS and

Prisma Access

Security policy rule construction, including applications, users, Security profiles, logging, and URL Filtering

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.

Critical Concepts for Security Policy—How Security policy rules work.

Rule Name, Description, Audit Comments, and Tags—Best practices for managing Security policy rules.

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

Applications and Services—Best practices for adding applications to rules.

Website Access (URL Filtering)—Best practices for how to allow user access to external websites.

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.

Security Profiles—Best practices for applying Security profiles to Security policy rules.

Critical Concepts for Security Policy

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.

Allow vs. block rules
—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 (

interzone-default

) and automatically allow all traffic between the same zone (

intrazone-default

). 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.

Allow access to non-business applications that you tolerate for the benefit of your employees.

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.

Rule Name, Description, Audit Comments, and Tags

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.

Name

—Identifies what each rule does.

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.

Description

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

To ensure all policies have a description in PAN-OS and

Panorama Managed Prisma Access

, enable

Require description on policies

Panorama

Setup

Management

Policy Rulebase Settings

(

Device

Setup

Management

Policy Rulebase Settings

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

Cloud Managed Prisma Access

, ensure that administrators enter a description.

Sources and Destinations

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.

Granular source and destination control helps you implement least privilege access:

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

Destinations—Zones, addresses, and devices.

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.

Panorama Managed Prisma Access

uses two zones, trust and untrust. Map Panorama zones to the

Prisma Access

trust or

Prisma Access

untrust zone.

Cloud Managed Prisma Access

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

any

and for outbound traffic specify the source address as

any

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.

Use Palo Alto Networks predefined External Dynamic Lists (EDLs) as the source or destination to block traffic to and from high-risk, bulletproof, and other malicious IP addresses.

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

any

as the destination. For outbound traffic, specify

any

as the source and the geographical region as the destination.)

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.

Create user groups based on the context what does the user need to do for business purposes—what are the common access requirements?
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.

If your deployment allows it, use the Cloud Identity Engine (CIE) to:

Aggregate all User-ID sources across your network, both cloud and on-premises.

Synchronize the directory sources.

Provide consistent User-ID information across the network.

Consistent User-ID enables policy to follow users everywhere in the network.

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

any

user,

pre-logon

users,

known-user

(authenticated), or

unknown

(not authenticated) users:

Use

any

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

Allow no

unknown

users on your network. Create a rule to block unknown users. Alternatively, use

unknown

for guest access providing that you allow no access to your corporate network.

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.

Follow User-ID best practices.

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:

> show iot ip-device-mapping-mp all

—View all IP address-to-device mappings on the firewall.

> show iot ip-device-mapping-mp ip <ip-address>

—View the IP address-to-device mapping for a specified IP address.

Follow IoT Security best practices.

Applications and Services

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.

Use application groups
as much as possible to simplify and tighten Security policy rule creation and reduce the size of the rulebase.

Application groups are user-defined sets of applications that require similar security treatment. Adding an application group to a Security policy rule enables you to control multiple applications with one rule instead of creating a separate rule for each application. If you need to add an application to the group or make any other changes, you only have to make the change once instead of making the change in every rule because when you update an application group, the rules that reference it are automatically updated.

Whether you are adding applications to an application group or to an individual Security policy rule, specify the exact functional applications you want unless you’re using a group to block a container application (which blocks all of its functional applications) or you want to allow access to all of a container application’s functional applications.

Application dependencies occur when an application needs other applications (dependent applications) to work properly. Application dependencies only matter for applications that you allow, not for applications that you block. There are two types of dependent applications:

Explicit applications, which the firewall shows you when you add an application to the rule and which you add manually so that the application works properly. For example, the facebook-chat application depends on adding the facebook-base and mqtt-base applications manually.

Implicit applications, which the firewall automatically allows to support the specified application and which you don’t need to explicitly add to a rule. For example, in addition to the explicit applications required for facebook-chat to work properly, when you add facebook-chat to a rule the firewall automatically allows the applications jabber and web-browsing. (Unless you explicitly add them to a rule, jabber and web-browsing aren’t allowed for all traffic, just for the facebook-chat traffic.)

Be aware of which applications you allow implicitly when you allow an application.

You can see an application’s dependencies in several ways:

The

Applications

object provides a searchable database of applications. Select an application to see its explicit application dependencies (

Depends on

) and its implicit application dependencies (

Implicitly Uses

Palo Alto Networks applipedia is a searchable database of content-delivered App-IDs. Search and select an application to see its explicit application dependencies (

Depends on Applications

) and its implicit application dependencies (

Implicit use Applications

When you add an application to a Security policy rule, the firewall shows you the explicit dependent applications but not the implicit dependent applications.

Commit Validate

to see application dependencies based on the entire Security policy rulebase instead of on just one rule.

Each network environment and business is different, so how to handle applications dependencies is not a one-size-fits-all recommendation. There are two ways to approach application dependencies, depending on your business and security requirements:

Focus on availability—Add all of the dependent applications shown in a Security policy rule to the rule to ensure that the application functions properly. For example, for the rule that controls facebook-chat, add facebook-base and mqtt-base to the rule.

However, this might result in some common dependent applications, such as ssl, being added to many rules instead of just to one rule, which adds clutter to the rulebase. (Even if the rulebase already allows ssl, ssl appears as a dependent application for many other applications.) A good way to mitigate this is to use Policy Optimizer to remove duplicate occurrences of dependent applications.

Focus on security—To allow as few applications as possible, run a

Commit Validate

to see all of the application dependencies in the Security policy rulebase. Add the dependencies you need based on the Commit Validate output. Consider creating application groups for different sets of application dependencies (e.g., VMware dependencies, software update dependencies, etc.) that contain all of the dependent applications you want to allow so that you can control access based on users.

In new and existing deployments, block known malicious and risky traffic immediately.

Block potentially malicious traffic based on trusted threat intelligence sources, including Palo Alto Networks built-in External Dynamic Lists (EDLs), which require an Advanced Threat Prevention or Threat Prevention subscription and block bulletproof IP addresses, high-risk IP addresses, known malicious IP addresses, and IP addresses known as Tor exit nodes.

Block encrypted DNS to maintain visibility into the traffic and to inspect the traffic for threats using Threat profiles. Attackers use DNS for many types of attacks, so you must inspect DNS traffic. Block both DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT), and use the Palo Alto Networks DNS Service. If you can’t block encrypted DNS immediately, gain visibility into the traffic and transition to blocking DoH and (DoT) traffic.

Because of App-ID’s granularity, you can allow regular DNS traffic in one rule and block DoT and DoH traffic in another rule because each has a different App-ID that you can specify in a Security policy rule.

Bad actors often use file sharing applications to exfiltrate data. Block most file sharing applications and allow access to business file sharing applications only to users who need those applications for business purposes. An easy way to accomplish this is to create a rule that specifies the users and has an application filter that includes the subcategory

file-sharing

and/or the tag

Uploading

Constructing allow-list based Security policy implicitly blocks most unwanted applications, so you don’t need many block rules. Base what you block on your business requirements by allowing only the application traffic that you want on your network and by thinking about who needs to use each application.

Set the

Service

application-default

in most cases. Because App-ID is based on signatures instead of port and protocol (which can be spoofed), App-ID is very accurate, so you don’t need to specify the port. Using application default prevents any application except the legitimate application from using the port and stops evasive applications from using non-standard ports. If in the future the default port for the application changes, application-default automatically applies the new port so you don’t have to reconfigure service port settings.

Only specify service ports if you have a custom application, special architectural requirements, or if your company security requirements demand it.

For internal applications and applications for which there is no App-ID, create custom applications to gain layer 7 visibility into traffic. Don’t use Application Override policy because it bypasses layer 7 processing and threat inspection. The use cases for Application Override are unusual situations with SMB or SIP traffic.

Use application filters
to discover traffic on your network and to handle new 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 which applications are in an application filter, which can lead to broader membership and allowing more applications than you need to allow. That’s why they’re best for discovering traffic so that you can control it.

Use cases include:

In new deployments where you’re not yet familiar with the traffic, use application filters to analyze different categories and subcategories of traffic so you can discover which of those types of applications are on your network.

You can create application filters to discover traffic of different types in mature deployments as well.

Filtering the rulebase for new applications. Create a filter that matches new applications and place the rule near the top of the rulebase. Use Policy Optimizer to gain visibility into the applications and control them.

Content updates control new applications. When an Applications content update is released, the new applications are seen as new until the next Applications content update is released. Releases normally occur on or around the third Tuesday of each month. After the next set of new applications are released, the previous set of new applications is no longer seen as new, and the application filter no longer matches them. Follow Best Practices for Applications and Threats Content Updates and decide how to handle the new applications before the next Applications content update .

In migration scenarios, use application filters to block or allow broad ranges of specific application types and then use Policy Optimizer to narrow them down to only the applications you want on the network. Application filters also enable you to ensure that certain types of new applications are allowed automatically when they match a filter.

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.

Application definitions are not static. Applications content updates can change an application’s definition and therefore how the rules treat the application. Follow best practices for Applications Content Updates to ensure that you have the time to make any necessary changes due to the update.

Website Access (URL Filtering)

Advanced URL Filtering requires a license. Use Advanced URL Filtering with PAN-OS,

Prisma Access

(usually included with the

Prisma Access

license), and Cloud NGFW for AWS.

URL Filtering based on website categories simplifies outbound Security policy and protects you from malicious websites. Each URL category defines a group of sites that have the same type of content, for example,

health-and-medicine

games

, or

hacking

sites. There are also three categories that define the relative risk level of sites within a particular category:

low-risk

medium-risk

, and

high-risk

. Combining a category with a risk level enables you to create Security policy rules that block or allow traffic based on risk within a URL category.

You must enable decryption to take advantage of URL Filtering because you must decrypt traffic to reveal the exact URL so the firewall can take the appropriate action. At the least, decrypt high- and medium-risk traffic.

Target traffic to decrypt based on URL categories because URL categories enable you to easily identify risky traffic.

Decrypt the riskiest URL categories first and decrypt more traffic as you gain experience.

In Security policy rules that control outbound internet traffic:

Attach URL Filtering profiles to simplify Security policy. Configure a best practices URL Filtering profile that blocks all categories of malicious websites (for both Site Access and User Credential Submission) and alerts on all other categories, and attach it to all rules that allow web access.

Control traffic that you can’t decrypt for legal, compliance, business, privacy, regulatory, or other reasons with URL categories. For example, create a Security policy rule, with the appropriate users and applications, that specifies the appropriate categories as match criteria and don’t decrypt traffic that matches the rule.

Configure custom URL categories so that you can create exceptions to URL Filtering based Security policy rules. Add the custom URL category to a URL Filtering profile and attach it to the appropriate Security policy rule or use custom categories as match criteria in Security policy. Exceptions enable you to block access to URL categories for most users but allow them for specific users such as PEN testers and infosec, block an entire category such as social networking but allow access to LinkedIn, or control what to decrypt. For example:

Combine a URL category with a risk-based category as match criteria to block or allow a URL category’s traffic based on risk. For example, to block access to risky finance sites, create a Security policy rule that specifies both the

financial-services

URL category and the

high-risk

category as match criteria and set the rule

Action

Deny

. Place this rule above rules that allow access to the

financial-services

URL category so that the firewall blocks high-risk sites before allowing access to the medium- and low-risk sites.

If firewall resource availability prevents you from decrypting all the traffic that you can decrypt legally and for business purposes, use custom URL categories to create Security policy rules with matching low-risk traffic for which there is little value in decryption. For example, to bypass decryption for low-risk streaming services, create a Security policy rule that specifies both the

streaming-media

URL category and the

low-risk

category as match criteria and set the rule

Action

Allow

. If the traffic uses TLSv1.2 or earlier, create a No Decryption policy and profile for the traffic to block bad sessions. If the traffic uses TLSv1.3 or later, don’t create a No Decryption policy and profile for the traffic.

Set the source zone in the Security policy rule to a protected internal network (trust zone). Do not specify an external zone or

any

zone as the source because you apply URL Filtering only to outbound traffic. (Applying URL Filtering to inbound traffic can even lead to DoS attacks.)

To transition URL Filtering profiles safely to best practice settings and create best practices URL Filtering profiles:

Clone the default URL Filtering profile (named

default

) and edit it.

Rename the profile appropriately (e.g., Best Practices URL Filtering Profile).

Set all actions for URL categories to alert for both Site Access and User Credential Submission. (The default allow action does not generate logs.) You must manually set URL categories to alert to generate logs and gain visibility into the traffic.

When a new category is added to URL Filtering, by default, the category is set to allow Site Access and User Credential Submission. Manually set new categories to alert on Site Access and User Credential Submission to get their URL Filtering logs. Also update custom URL categories accordingly.

Set all actions for malicious URL categories to block both Site Access and User Credential Submission. Make appropriate exceptions for PEN testing, threat research, and infosec as needed:

command-and-control—URLs and domains that malware or compromised systems use to communicate with an attacker’s remote server.

grayware—These sites don’t meet the definition of a virus or pose a direct security threat, but they influence users to grant remote access or perform other unauthorized actions. Grayware sites include scams, illegal activities, criminal activities, adware, and other unwanted and unsolicited applications, including “typosquatting” domains.

malware—Sites known to host malware or used for command-and-control activities.

phishing—Sites known to host credential and personal information phishing pages, including technical support scams and scareware.

ransomware—Sites that are known to distribute ransomware.

scanning-activity—Probing for existing vulnerabilities or conducting targeted attacks.

Some URL categories have the strong potential to be malicious but are not definitely malicious. Set all actions for these URL categories to block both Site Access and User Credential Submission. Make appropriate exceptions for PEN testing, threat research, and infosec as needed:

dynamic-dns—Systems with dynamically assigned IP addresses that are often used to deliver malware payloads or command-and-control malware.

hacking—Sites relating to illegal or questionable access to or use of equipment and software. Includes sites that facilitate the bypass of licensing and digital rights systems.

Make exceptions to this category for the appropriate PEN testing and threat research users.

insufficient-content—Websites and services that present test pages, no content, provide API access not intended for end-user display, or require authentication without displaying any other content.

newly-registered-domains—Domains that domain generation algorithms often generate or bad actors generate for malicious activity.

not-resolved—If the PAN-DB cloud is unreachable and the URL is not in the firewall’s URL Filtering cache, the firewall cannot the resolve and identify the URL category.

For highest security, enable

Hold client request for category lookup

to give the firewall more time to resolve the URL category. This extends the time the firewall has to query the category type from the cloud and results in better security but might increase latency.

parked—Domains that will often be used for credential phishing or personal information theft.

proxy-avoidance-and-anonymizers—URLs and services often used to bypass content filtering products.

unknown—Sites not yet identified by Palo Alto Networks (PAN-DB).

PAN-DB real-time updates learn unknown sites after the first attempt to access an unknown site, so the firewall identifies unknown URLs quickly and then handles them based on the actual URL category of the site.

If availability is critical to your business and you must allow traffic from unknown sites, apply the strictest Security profiles to the traffic and investigate all alerts for the traffic.

Set the action for Site Access and User Credential Submission to block the following URL categories based on legal or business requirements and potential liability risk. If you don’t block these sites, alert on and apply strict Security profiles to the traffic.

abused-drugs—Sites that promote illegal and legal drug abuse.

adult—All sites that contain adult content of any kind, including games and comics as well as sexually explicit material, media, art, forums, and services.

extremism—Websites promoting terrorism, racism, child exploitation, etc.

gambling—Lottery and gambling sites.

peer-to-peer—Peer-to-peer sharing of torrents, download programs, media files, or other software applications. (Does not include shareware or freeware sites.)

questionable—Sites that promote tasteless humor, offensive content targeting specific demographics.

weapons—Sale, review, descriptions of, or instructions regarding weapons and their use.

Also consider how you want to handle the cryptocurrency and alcohol-and-tobacco URL categories. Either alert on them and apply strict Security profiles to the traffic or block them, depending on your business needs.

Block User Credential Submission for the high-risk category. (Do not block Site Access for the high-risk category.)

For the URL Filtering Settings in the URL Filtering profile:

Disable

Log Container Page Only

, which is enabled by default. If you only log container pages, you lose visibility into functional applications such as posting, uploading, downloading, etc. Disable

Log Container Page Only

to see the complete log so that you see the real functional application.

If your environment is a school that takes federal funding, enable

Safe Search Enforcement

(legal requirement).

Enable

User Credential Detection

(requires configuring and enabling User-ID).

Apply URL Filtering to Security policy rules with DNS Sinkhole configured in the Anti-Spyware Security profile (requires an Advanced Threat Protection or active legacy Threat Protection subscription and a DNS Security subscription to use cloud-based DNS security) to see which machines are infected and where they were trying to connect for DNS.

Policy Actions and Other Settings

Security policy actions specify whether to allow or block traffic, and how to block traffic you don’t allow it. Quality of Service (QoS) controls bandwidth, if needed, to ensure that the traffic a rule allows receives the appropriate bandwidth.

Define an action for each Security policy rule.

Allow

only sanctioned and tolerated traffic. The more traffic you allow that doesn’t pertain to your business, the greater the risk. The firewall blocks traffic that you don’t explicitly allow in a Security policy rule.

The more your Security policy rules follow the principle of least privilege access, the fewer block rules you need. How to block traffic depends on how you want to respond to the application that you’re blocking.

Use

Deny

, which uses the application’s default action, unless you want the firewall to respond to the application in a specific way by resetting the client, server, or both, or by silently dropping the traffic.

Use

Drop

when you want to deny service silently, without sending a reset response. When you block clearly malicious traffic, such as when you block based on the predefined Palo Alto Networks EDLs, the

Drop

action prevents the malicious end of the communication from knowing why it was blocked.

If you have a use case for resetting only the client or only the server, ensure that you understand the client-server directionality (which end of the communication initiates the connection), which is based on the rule’s source and destination settings.

If necessary, apply QoS to control bandwidth for certain applications.

QoS is optional. Understand the applications you want to prioritize for bandwidth and the applications whose bandwidth you want to limit if you apply QoS to policy. For example, during popular events such as the World Cup that use particular streaming applications, you can allow employees to view the event using those applications and limit their bandwidth to ensure that appropriate bandwidth is available for business activities. Another example is when updates are released for popular applications, mass downloading can impact bandwidth availability. To prevent that, apply QoS to limit the bandwidth available for that application’s download traffic.

Logging and Log Forwarding

Logging and storing logs are critical for investigating incidents. Communicate with your:

Security Operations Center (SOC) to ensure that you capture the right information to investigate events if necessary.

Audit compliance team to ensure that you capture the right information for audits and compliance.

Legal team to ensure that you don’t store cleartext or other data that violates local regulations, compliance, business requirements, privacy, etc.

Consider the log storage capacity you need now and in the future and size your log storage capacity accordingly.

Plan storage capacity so that you can retain logs long enough to investigate threats. The length of time depends on your investigation procedures.

Ensure that your SOC can ingest logs from wherever you store them.

Cortex Data Lake

centralizes log storage and analysis and provides a solution that scales with your log volume.

Don’t duplicate the same logs for storage in multiple places. Use either

Cortex Data Lake

or a separate storage space such as Log Collectors. When moving logs from one storage space to another, don’t use duplication. Instead, prepare for and execute a hard cutover instead.

If you enable duplicate log forwarding on firewalls or Panorama, System and Configuration logs are not sent to

Cortex Data Lake

so the

Cortex Data Lake

logs will be incomplete. For this reason, do not enable duplicate log forwarding for log backup.

If you must split log storage, do it by separating log forwarding in a consistent manner. For example, send all

Prisma Access

logs to

Cortex Data Lake

and send all firewall logs to Log Collectors.

Think about what you want to log, how you want to log it, and what you don’t want to log or can’t log for compliance or storage space reasons.

For most applications, log all the information you can to help with Security Operating Center (SOC) investigations. However, there are some applications and circumstances for which you can’t take comprehensive logs:

Assess whether the rule needs logging based on compliance, business requirements, audit requirements such as ISO, privacy considerations (e.g., PII, GDPR), and SOC requirements. Be careful about logging SSNs, credentials, PII, etc., in cleartext if applications don’t encrypt that information.

Basic services such as DNS, NTP, syslog, etc., create thousands of small sessions that result in many unnecessary logs, which impacts log storage and makes investigating incidents more difficult. For these services, configure only Threat log forwarding unless you have the storage capacity to take other logs.

In Security policy rules, log traffic at the end of the session instead of at the start to avoid logging transient applications.

Log At Session Start

also consumes more resources than logging only at the session end. In most cases, you only

Log At Session End

. Enable both

Log At Session Start

and

Log At Session End

only for troubleshooting why an application doesn't match a Security policy rule, to see active long-lived tunnel sessions such as GRE tunnels (you can't see these sessions in the ACC unless you log at the start of the session), and to gain visibility into Operational Technology/Industrial Control Systems (OT/ICS) sessions, which are also long-lived sessions.

Policy Optimizer and the Cloud App-ID Engine (ACE) do not count rules that Log at Session Start in their statistics.

Log traffic that matches the intrazone-default rule, which allows all traffic within a zone by default, and the interzone-deny rule, which blocks all traffic between zones that Security policy rule doesn’t explicitly allow by default.

Configure Log Forwarding profiles and assign them to Security policy rules to send logs to the appropriate storage, such as

Cortex Data Lake

or Log Collectors, and to alert the appropriate administrators about events, especially critical, high, and medium threat events.

Cloud Managed Prisma Access

forwards all logs to

Cortex Data Lake

Ensure that every Security policy rule has a Log Forwarding profile attached.

Create a basic default Log Forwarding profile for all new Security policy rules and name it

default

and make sure it logs threats. Naming the profile

default

makes the firewall apply it to all new Security policy rules automatically, so it ensures that all new rules have Log Forwarding profiles.

It’s easier to replace or modify the profile for the few rules that require different logging treatment, such as logs for traffic related to compliance, personal information, local regulations, business requirements, etc., or logs for common services such as DNS or NTP, than it is to attach a Log Forwarding profile to every new rule individually.

For Security policy rules that govern IoT Security, use the

IoT Security Default Profile - EAL Enabled

predefined Log Forwarding profile, which provides IoT Security with all the log types it requires, including enhanced application logs.

Use

Log Forwarding for Security Services

in Policy Optimizer to identify Security policy rules that don’t have a Log Forwarding profile attached (select

None

in the filter). Add an appropriate Log Forwarding profile to each rule that has none.

For investigation purposes, ensure that you know the true source and destination of traffic, not just the IP address of a proxy device such as a load balancer, NAT device, or malicious DNS server that’s between the true source and the firewall. If there is a proxy device between the firewall and the true source, depending on your network architecture and the application:

Place firewalls in front of load balancers to see the real source IP address.

Take a pre-NAT Packet Capture by configuring a receive stage in the packet capture settings.

Apply a URL Filtering profile that enables logging the X-Forwarded-For (XFF) field field to the Security policy rule (

URL Filtering Settings

tab in

Objects

Profiles

URL Filtering

). The XFF field shows the original source IP address. The XFF log is in the URL Filtering Log.

Security Profiles

Security profiles scan allowed traffic for threats such as viruses, malware, spyware, malicious file types, and other known and unknown threats, and prevent those threats. Attach Security profiles to Security policy rules that allow traffic to apply threat prevention to traffic that matches the rule.

Use Day 1 Configurations for templates that provide use-case agnostic best practices Security profiles to allowed traffic right way. Day 1 Configurations are available on the Customer Support Portal (

Tools

Run Day 1 Configuration

) and require support login. From there, transition to best practices threat blocking as described here.

To identify and prevent threats, the firewall must have visibility into application traffic. Decrypt as much traffic as local regulations, business considerations, privacy considerations, and technical ability allow. For SSL Forward Proxy (outbound) decryption, implement User-ID and URL Filtering first so you can target decryption effectively. If you don’t decrypt traffic, the firewall can’t analyze encrypted headers and payload information.

Follow Threats Content Update best practices to ensure that your Security profile signatures are up to date.

Get the Advanced Threat Prevention cloud service subscription to prevent threats including unknown command-and-control and zero-day vulnerability threats in real time. Advanced Threat Prevention is available for PAN-OS and for

Prisma Access

3.2 Innovation and later Innovation deployments. If you run an earlier version of

Prisma Access

, use the regular Threat Prevention subscription.

Air-gapped environments cannot use Advanced Threat Prevention because it’s a cloud service and requires a cloud connection.

The best practice Security profile recommendations for differ slightly from the recommendations for PAN-OS and

Panorama Managed Prisma Access

. In addition, in

Cloud Managed Prisma Access

, you cannot apply individual Security profiles to Security policy rules, you can only apply Profile Groups. Profile Groups include the Security profiles that you include in the group.

Best practices advice focuses on what to do to be most secure, and that’s the ultimate goal for your Security profiles. However, to ensure the availability of business-critical applications, start by blocking known malicious traffic and alerting on most other traffic. Follow best practice Security profile transition advice to move safely from alerting to best practice Security profiles that block traffic and exercise caution when moving from alert to blocking to avoid impacting business-critical applications.

The time to transition a Security profile setting from alert to block is when you’re confident that the profile is appropriately tuned, you’ve made any necessary exceptions, and you won’t inadvertently trigger a signature that blocks a business-critical application.

This streamlined section shows you the best practice settings. Create Best Practice Security Profiles provides more in-depth information about the reasons for the settings.

Antivirus profile (includes WildFire signature and inline machine learning actions)

Anti-Spyware profile (includes DNS Policies/sinkholing and inline cloud analysis)

To provide comprehensive coverage, get an Advanced URL Filtering subscription and a DNS Security subscription to gain visibility into and protect against malicious URLs, domains, and abuses of the DNS protocol.

Vulnerability Protection profile (includes inline cloud analysis)

File Blocking profile

WildFire Analysis profile

Clone the predefined default Antivirus profile, rename it, and edit it as you transition the Antivirus profile safely to best practices settings.

To transition the Antivirus profile safely to a best practices profile:

False positives are rare. Deploy the best practices Antivirus profile for applications that aren’t critical to your business right away.

For business-critical applications, start by alerting to ensure that you don’t affect the availability of critical applications. Transition to blocking when you feel comfortable that the Antivirus profile doesn’t block these applications.

If you have an existing deployment or are migrating and you have an existing block in place, replicate it because you already understand the traffic and why you’re blocking it.

If you treat internal applications differently than external applications, you might need an Antivirus profile for internet-facing traffic and a different Antivirus profile for internal traffic.

Monitor the Threat logs to see whether any business-critical applications cause alerts or blocks. Monitor the WildFire Submissions logs if you have an Advanced WildFire or legacy WildFire subscription and use the WildFire action settings.

A best practices Antivirus profile blocks known malware, viruses, and ransomware bots:

Enable real-time signature lookup globally on the device and in the Antivirus profile to hold files until the firewall receives the latest real-time antivirus signature from the cloud:

Enable globally—

Device

Setup

Content-ID

Content-ID Settings

Realtime Signature Lookup

, enable

Hold for WildFire Real Time Signature Look Up

, and set the

Action On Real Time Signature Timeout

Reset Both

. You must enable real-time signature lookup globally to enable in Antivirus profiles.

Enable in Antivirus profile—

Objects

Security Profiles

Antivirus

and enable

Hold for WildFire Real Time Signature Look Up

Holding files to ensure that WildFire gets the latest antivirus signatures protects you from zero-day malware and outdated antivirus signatures that you might be exposed to if you forward files without holding them for the latest signatures.

Set the actions to take when the firewall detects viruses in certain protocols. The safest action is to reset both the client and the server to ensure that the session is terminated:

Change the

Signature Action

reset-both

for the smtp, pop3, and imap protocols, whose default action is to alert. Leave the

Signature Action

for the other protocols on

reset-both

Change the

WildFire Signature Action

reset-both

for the smtp, pop3, and imap protocols, whose default action is to alert. Leave the

WildFire Signature Action

for the other protocols on

reset-both

Change the

WildFire Inline ML Action

reset-both

for the smtp, pop3, and imap protocols, whose default action is to alert. Leave the

WildFire Inline ML Action

for the other protocols on

reset-both

Attach a best practices profile to all allow rules.

A WildFire subscription is required to configure WildFire Signature Action and WildFire Inline ML Action.

Cloud Managed Prisma Access

, Antivirus and WildFire come together in one profile instead of having separate profiles.

Clone the predefined default Anti-Spyware profile, rename it, and edit it as you transition the Anti-Spyware profile safely to best practice settings. In addition to Anti-Spyware signature policies, the profile also controls DNS sinkhole policies.

To transition the Anti-Spyware profile safely to a best practices profile, in

Signature Policies

False positives are relatively rare. For applications that aren’t critical to your business, block critical and high severity signatures from the start.

Medium severity signatures might generate false positives, so they require initial monitoring. Alert on medium severity signatures for internal traffic and block medium severity signatures for external-facing traffic. Monitor the Threat logs (

Monitor

Logs

Threat

) to see if you can block applications for which you receive alerts or if you need to allow them.

For business-critical applications, set the

Action

alert

to ensure application availability. However, if you already protect applications with an Anti-Spyware profile that blocks critical, high, and/or medium signatures, and you’re confident the profile meets your business and security needs, use a similar profile to block spyware and protect those applications.

Enable single packet capture for all severity signatures during the transition so you can investigate events in greater detail if necessary if you have the resources. As you move to best practice profiles, if low and informational events create too much packet capture activity (too large a volume of traffic) and the information isn’t particularly useful, transition to disabling packet capture on those severities.

Packet captures consume management plane resources. Check system resources (for example,

Dashboard

System Resources

) to understand usage before and after you implement packet capture to ensure that your system has sufficient resources to take all the packet captures.

Create exceptions as needed to remediate any confirmed false positives before you implement full best-practice Anti-Spyware profiles.

If you treat internal applications differently than external applications, you might need an Anti-Spyware profile for internet-facing traffic and a different Anti-Spyware profile for internal traffic.

Transition the profile’s

DNS Policies

to best practices as soon as you are comfortable that you understand the traffic you’re blocking:

Set the

Policy Action

for DNS signatures to

sinkhole

to identify potentially compromised hosts that attempt to access suspicious domains by tracking the hosts and preventing them from accessing those domains. Set

Packet Capture

extended-capture

On PAN-OS systems, set the DNS Sinkhole address as the FQDN, for example, sinkhole.paloaltonetworks.com, so that if the IP address changes, the setting is still valid. For Prisma Access, use the sinkhole IP address.

Sinkhole all of the

DNS Security

domain types and set

Packet Capture

extended-capture

for Command and Control Domains and

single-packet

for all other domain types except Parked Domains (PAN-OS 10.0 and later).

Block all DNS record types, which are used by encrypted DNS queries, to prevent clients from encrypting the client hello during the DNS resolution process.

Set the profile’s

Inline Cloud Analysis

(requires Advanced Threat Prevention subscription and PAN-OS 10.2 and later) to

Enable cloud inline analysis

on all outbound traffic. Set the

Action

reset-both

for all models.

In the transition Anti-Spyware profile, if you have existing antispyware controls that block traffic and meet your business needs, implement those controls immediately because you already understand the traffic and why you’re blocking it.

A best practices Anti-Spyware profile profile detects command-and-control (C2) traffic, prevents compromised systems from establishing an outbound connection, and enables DNS sinkholing to identify infected hosts. Use GlobalProtect to automatically quarantine a compromised device in PAN-OS and with

Panorama Managed Prisma Access

, and you can also quarantine compromised devices in .

For

Signature Policies

Set the

Action

for critical, high, and medium severities to

reset-both

and set

packet-capture

single-packet

Set the

Action

for low and informational severities to

default

and disable

packet-capture

For

DNS Policies

, use the same settings recommended for the transition period. Set the

Policy Action

to sinkhole for all signature sources, set

Packet Capture

extended-capture

for

Palo Alto Networks Content

and Command and Control Domains, and set

Packet Capture

single-packet

for all other DNS Security domains except Parked Domains.

The best practice settings for

Inline Cloud Analysis

are the same as the transition settings. Enable the feature on all outbound traffic and set the action to

reset-both

Use the DNS Security service to protect you from advanced DNS-based threats (requires DNS Security license and Advanced Threat Prevention or active legacy Threat Prevention subscription).

Attach a best practices profile to all allow rules.

Clone the predefined strict Vulnerability Protection profile, rename it, and edit it as you transition the Vulnerability Protection profile safely to best practices settings.

Vulnerability Protection profiles defend against buffer overflows, illegal code execution, and other attempts to exploit client-side and server-side vulnerabilities. To transition the Vulnerability Protection profile safely to a best practices profile:

False positives rates are low. Set rules for applications that aren’t critical to your business to block (

reset-both

) right away.

For business-critical applications, start by alerting to ensure that you don’t affect the availability of critical applications. Transition to blocking when you feel comfortable that the Vulnerability Protection profile doesn’t block these applications.

If you have an existing deployment or are migrating and you have an existing block in place, replicate it because you already understand the traffic and why you’re blocking it.

Set signatures in the

brute-force

category for critical, high, and medium severities to alert and fine-tune them until you can comfortably transition to blocking. Set

Packet Capture

extended-capture

Set signatures for critical and high severity rules to

reset-both

and set

Packet Capture

single-packet

Set signatures for medium severity rules to

alert

and set

Packet Capture

extended-capture

Set signatures for low and informational severity rules to

default

and set

Packet Capture

single-packet

For

Inline Cloud Analysis

, use the same criteria for alerting versus blocking business applications that you use for the initial Vulnerability Protection rules. If you have existing controls, replicate them to block traffic. For new controls, alert for at least a week before transitioning to blocking. Move to blocking as soon as you can.

Packet captures consume management plane resources. Check system resources (for example,

Dashboard

System Resources

) to understand usage before and after you implement packet capture to ensure that your system has sufficient resources.

Monitor the Threat logs to see whether any business-critical applications cause alerts or blocks. Monitor the WildFire Submissions logs if you have a WildFire subscription and use the WildFire actions.

The best practices Vulnerability Protection profile controls how to handle client-side and server-side vulnerabilities for critical, high, medium, low, and informational event severities. In the profile, configure six rules:

Create the same three rules that prevent brute force attacks in the transition profile and set the

Action

reset-both

and

Packet Capture

single-packet

Combine simple-client-critical, simple-client-high, simple-client-medium, simple-server-critical, simple-server-high, and simple-server-low severities in one rule. Set the

Action

reset-both

and set

Packet Capture

single-packet

For profiles that control internal (east-west) traffic, blocking medium severity events might impact business applications. If blocking impacts business applications, create a separate rule in the profile for medium severity events with the

Action

set to

alert

. Apply this profile only to internal traffic.

For simple-client-low and simple-server-low severities, set the

Action

default

and set

Packet Capture

single-packet

For simple-client-informational and simple-server-informational severities, set the

Action

default

and

disable

packet capture. (Informational activity might generate a relatively high volume of packet capture traffic that isn’t particularly useful compared to potential threat packet captures.)

Set the

Inline Cloud Analysis

actions to

reset-both

To control Vulnerability Protection profiles more granularly and fine-tune Vulnerability Protection for a particular use case, create separate rules in the profile for each severity for both client-side and server-side detection. When the action and packet capture settings are the same, it makes sense to combine them in one rule to simplify configuration.

Attach a best practices profile to all allow rules.

Transition your File Blocking profiles from alerting to blocking all potentially malicious file types.

Cloud Managed Prisma Access

does not support File Blocking profiles for Security policy rules.

File Blocking profiles block potentially malicious file types used in cyberattacks. To transition File Blocking profiles safely to best practice settings to a best practices profile:

For business-critical applications, alert for all file types and move to a best practices File Blocking profile as soon as possible. If you already have blocking controls in place, replicate them and continue to block traffic that you already know you want to block.

For applications that are not business-critical, start the transition to a best practice File Blocking profile:

Inbound and outbound traffic
—Block 7z, bat, chm, class, cpl, dll, dlp, hta, jar, ocx, pif, scr, torrent, vbe, and wsf files. Alert on all other files.

Internal traffic
—Block 7z, bat, chm, class, cpl, dlp, hta, jar, ocx, pif, scr, torrent, vbe, and wsf files (this is the same as the inbound/outbound profile except it alerts on .dll files instead of blocking them). Alert on all other files.

Block any of the following file types that you can for users who don’t need them for business purposes: cab, exe, flash, msi, Multi-Level-Encoding, PE, rar, tar, encrypted-rar, and encrypted-zip.

If necessary, create exceptions for IT groups and others who need legitimate business access to any of these file types. If you already block any other file types, continue to block them.

Transition to a best practices File Blocking profile as quickly as you are comfortable with doing so.

The predefined

strict file blocking

profile blocks file types that are typically used in cyber attacks and that have no real use cases for upload and download. However, a few protocols used for malicious purposes might also be required for activities such as Windows updates. The

strict file blocking

profile blocks .exe., .dll, .pe, and .cab files. To make exceptions to allow protocols for a specific activity such as Windows updates:

Create a specific Security policy rule that allows only the users who need access for business purposes and the business applications that use the protocols you want to block for other traffic.

Attach a File Blocking profile that allows the required protocols to the rule.

Place the rule above a Security policy rule with a File Blocking profile that blocks the protocols for all other traffic.

This method allows you to use potentially malicious file types in a safe way that enables business applications while blocking malicious traffic. Fine-tune the profiles and rulebase to allow any required exceptions.

Attach a best practices profile to all allow rules.

Attach the default WildFire Analysis profile to all allow rules to detect and prevent zero-day malware.

To get real-time updates and other advanced features, get an Advanced WildFire subscription (PAN-OS 10.0 or later) or a WildFire subscription.

Deploy the default WildFire profile, which is the best practice profile. WildFire doesn’t impact network traffic, so there is no transition period required. (However, the best practices WildFire Action settings in the Antivirus profile impact traffic that generates signatures that result in a reset or drop action or in a hold for looking up the latest antivirus signature.) Attach a WildFire Analysis profile to all allow rules to send all files to WildFire for analysis.

Cloud Managed Prisma Access

, WildFire and Antivirus come together in one profile, which you add to a

Prisma Access

profile group.

Security profile groups consist of individual Security profiles combined in a named group, which enables you to apply Security profiles more easily and consistently to Security policy rules.

Create Security profile groups for different conditions, based on the logic of your rulebase:

Each profile group should have a distinct purpose, such as creating profile groups specific to the flow of traffic. For example, a profile group for inbound traffic doesn’t need a URL Filtering profile, but a profile group for outbound traffic does.

Profile groups that are specific to the flow of traffic make it easier to make exceptions if you want to treat internally-facing and externally-facing traffic differently. For example, you might want to block something for internal traffic that you use and allow for external traffic. In that case, you would use different profiles for internal and external traffic. Whether you need separate profiles depends on how you want to treat the traffic.

To make transitioning profiles from alert to block easier, create profile groups for initial alerting and profile groups for best practice blocking. This makes it easy to alert on threats in all allow rules. As you become comfortable enough to move from alert to block, profile groups make it easy to make the change because you only have to swap out one object instead of each individual profile.

Consider creating a default profile group by naming the group

default

. For example, create a group with profiles that alert but don’t block most traffic, based on best practice Security profile transition advice. The firewall automatically applies the default profile group to all new Security policy rules that allow traffic. (The firewall does not apply the default profile to existing rules.) This ensures that all new allow rules have some level of threat prevention. Edit or replace the default profile as needed.

Deploy Security Policy Best Practices

Security Policy Rulebase Best Practices

Security Policy Best Practices

Security Policy Rule Best Practices

Security Policy Rule Best Practices

Critical Concepts for Security Policy

Rule Name, Description, Audit Comments, and Tags

Sources and Destinations

Applications and Services

Website Access (URL Filtering)

Policy Actions and Other Settings

Logging and Log Forwarding

Security Profiles

Recommended For You