Deploy Security Policy Best Practices
Expand all | Collapse all
Deploy Security Policy Best Practices
Deploy best practices Security policy in PAN-OS and Prisma Access.
Deploying Security policy best practices
includes:
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.
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.)
While planning and deploying, keep these principles in mind:
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.
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 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.
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.