Data Center Best Practices

Download as pdf or txt
Download as pdf or txt
You are on page 1of 118

Data Center Best Pracce Security

Policy
Version 10.1

docs.paloaltonetworks.com
Contact Informaon
Corporate Headquarters:
Palo Alto Networks
3000 Tannery Way
Santa Clara, CA 95054
www.paloaltonetworks.com/company/contact-support.html

About the Documentaon


• For the most recent version of this guide or for access to related documentaon, visit the
Technical Documentaon portal docs.paloaltonetworks.com.
• To search for a specific topic, go to our search page docs.paloaltonetworks.com/search.html.
• Have feedback or quesons for us? Leave a comment on any page in the portal, or write to us
at documenta[email protected].

Copyright
Palo Alto Networks, Inc.
www.paloaltonetworks.com
©2021 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto
Networks. A list of our trademarks can be found at www.paloaltonetworks.com/company/
trademarks.html. All other marks menoned herein may be trademarks of their respecve
companies.

Last Revised
March 9, 2021

Data Center Best Pracce Security Policy Version Version 10.1 2 ©2021 Palo Alto Networks, Inc.
Table of Contents
Data Center Security Policy Best Pracces Checklist...............................5
Plan Your Data Center Best Pracce Deployment.............................................................. 6
Deploy Data Center Best Pracces.........................................................................................9
Global Data Center Objects, Policies, and Acons.................................................. 9
User Data Center Traffic Policies............................................................................... 13
Internet-to-Data-Center Traffic Policies................................................................... 17
Data-Center-to-Internet Traffic Policies................................................................... 18
Intra-Data-Center Traffic Policies...............................................................................20
Data Center Security Policy Rulebase Order.......................................................... 21
Follow Post-Deployment Data Center Best Pracces......................................................23

Data Center Best Pracce Security Policy................................................ 25


What Is a Data Center Best Pracce Security Policy?..................................................... 26
Why Do I Need a Data Center Best Pracce Security Policy?.......................................27
Data Center Best Pracce Methodology............................................................................ 29
How Do I Deploy a Data Center Best Pracce Security Policy?....................................33
How to Assess Your Data Center......................................................................................... 35
How to Decrypt Data Center Traffic.................................................................................... 38
Create the Data Center Best Pracce Decrypon Profiles..................................39
Exclude Unsuitable Traffic from Data Center Decrypon....................................48
Create a Data Center Segmentaon Strategy....................................................................50
How to Segment the Data Center............................................................................ 50
How to Segment Data Center Applicaons............................................................ 51
How to Create Data Center Best Pracce Security Profiles...........................................55
Create the Data Center Best Pracce Anvirus Profile....................................... 56
Create the Data Center Best Pracce An-Spyware Profile............................... 56
Create the Data Center Best Pracce Vulnerability Protecon Profile............. 58
Create the Data Center Best Pracce File Blocking Profile.................................60
Create the Data Center Best Pracce WildFire Analysis Profile........................ 61
Use Cortex XDR Agent to Protect Data Center Endpoints.............................................63
Create Data Center Traffic Block Rules............................................................................... 64
Define the Inial User-to-Data-Center Traffic Security Policy....................................... 70
User-to-Data-Center Traffic Security Approaches................................................. 70
Create User-to-Data-Center Applicaon Allow Rules.......................................... 71
Create User-to-Data-Center Authencaon Policy Rules................................... 75
Create User-to-Data-Center Decrypon Policy Rules.......................................... 78
Define the Inial Internet-to-Data-Center Traffic Security Policy................................. 83
Internet-to-Data-Center Traffic Security Approach...............................................83

Data Center Best Pracce Security Policy Version Version 10.1 3 ©2021 Palo Alto Networks, Inc.
Table of Contents

Create Internet-to-Data-Center Applicaon Allow Rules.................................... 84


Create Internet-to-Data-Center Decrypon Policy Rules....................................86
Create Internet-to-Data-Center DoS Protecon Policy Rules............................ 87
Define the Inial Data-Center-to-Internet Traffic Security Policy................................. 90
Data-Center-to-Internet Traffic Security Approaches...........................................90
Create Data-Center-to-Internet Applicaon Allow Rules.................................... 91
Create Data-Center-to-Internet Decrypon Policy Rules.................................... 97
Define the Inial Intra-Data-Center Traffic Security Policy............................................ 99
Intra-Data-Center Traffic Security Approach.......................................................... 99
Create Intra-Data-Center Applicaon Allow Rules............................................. 101
Create Intra-Data-Center Decrypon Policy Rules............................................. 103
Order the Data Center Security Policy Rulebase............................................................105
Log and Monitor Data Center Traffic.................................................................................108
What Data Center Traffic to Log and Monitor.....................................................108
Monitor Data Center Block Rules and Tune the Rulebase................................ 110
Log Intra Data Center Traffic That Matches the Intrazone Allow Rule........... 112
Log Data Center Traffic That Matches No Interzone Rules...............................113
Maintain the Data Center Best Pracce Rulebase..........................................................115
Use Palo Alto Networks Assessment and Review Tools................................................117

Data Center Best Pracce Security Policy Version Version 10.1 4 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best
Pracces Checklist
Your enterprise’s most valuable assets reside in your data center, including proprietary
source code, intellectual property, and sensive company and customer data. Your
customers and employees trust you to maintain the confidenality and integrity of
their data and expect that data to be always available, so it’s important to implement
a data center best pracce security policy that safeguards your data and prevents
successful aacks. It’s not enough to harden the network perimeter because aacks
can originate from inside the network, aacks can come from partners and contractors
whose credenals have been compromised, and because if an aacker gains a
foothold in your network, the aacker can aack from the inside of the network by
moving laterally from device to device.
If you are familiar with Palo Alto Networks plaorm, you can save me by using
this streamlined checklist to implement pre-deployment, deployment, and post-
deployment data center security policy best pracces. Each secon includes links to
detailed informaon in the full Data Center Best Pracce Security Policy document or
in the PAN-OS 10.1 Admin Guide, including how to configure policy rules and security
profiles.

> Plan Your Data Center Best Pracce Deployment


> Deploy Data Center Best Pracces
> Follow Post-Deployment Data Center Best Pracces

5
Data Center Security Policy Best Pracces Checklist

Plan Your Data Center Best Pracce Deployment


Prepare to implement best pracces in your data center by developing a strategy and a roll-out
plan. Use posive security enforcement (create rules that allow the user and applicaon traffic you
want to allow and deny everything else) to work toward a Zero Trust architecture.
STEP 1 | Set goals.
Define the ideal future state of your data center network so you have definive goals to
work toward and know when you’ve achieved those goals.
Protect traffic flows from each area in which connecons are iniated:
1. Local user traffic flowing into the data center.
2. Traffic flowing from the internet to the data center.
3. Traffic flowing from the data center to the internet.
4. Traffic flowing between servers or VMs within the data center (intra data center east-
west traffic).
Don’t allow unknown users, applicaons, or traffic in your data center.
Create a standardized, scalable design you can replicate and apply consistently across data
centers.

STEP 2 | Work with stakeholders such as IT/support, security, and groups that require data center
access such as engineering, legal, finance, and HR, to develop an access strategy.
Idenfy users who need access, and the assets to which they need access. Understanding
this enables you to create user groups based on access level requirements so you can design
efficient Security policy rules by user group.
Idenfy the applicaons you want to allow (sancon) in the data center. To reduce the
aack surface, only sancon applicaons for legimate business reasons.

Data Center Best Pracce Security Policy Version Version 10.1 6 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

STEP 3 | Assess your data center to understand its current state so you can create a plan to transform
data center security to the desired future state.
Inventory the physical and virtual environment and assets, including:
Servers, routers, switches, security devices, load balancers, and other network
infrastructure.
Standard and proprietary custom applicaons and the service accounts they use to
communicate. Compare the applicaon inventory list to the list of applicaons you want
to sancon.

Focus on the applicaons you want to allow because your allow list Security
policy rules allow them and by default deny all other applicaons to reduce the
aack surface. Map applicaons to business requirements. If an applicaon
doesn’t map to a business requirement, evaluate whether you really need to
allow it.
Assess each asset to help priorize what to protect first. Ask yourself quesons such as,
“What defines and differenates our company?”, “What systems must be available for
daily operaons?”, and “If I lost this asset, what are the consequences?”
Work with applicaon, network, and enterprise architects, and with business
representaves to characterize data center traffic flows and learn about typical baseline
traffic loads and paerns so you understand normal network behavior. Use the Applicaon
Command Center widgets and traffic analysis tools to baseline traffic.

STEP 4 | Create a Data Center Segmentaon Strategy to prevent malware that gains a foothold in
your data center from moving laterally to infect other systems.
Use firewalls as segmentaon gateways to provide visibility into data center traffic and
systems so you can finely control who can use which applicaons to access which devices.
Segment and secure non-virtualized servers with physical firewalls and the virtual network
with VM-Series firewalls.
Use the firewall’s flexible segmentaon tools such as zones, dynamic address groups, App-
ID, and User-ID to design a granular segmentaon strategy that protects sensive servers
and data.
Group assets that perform similar funcons and require the same level of security in the
same segment.
Segment data center applicaons by segmenng the server ers that make up an
applicaon er (typically a service chain composed of a web server er, an applicaon
server er, and a database server er) and using the firewall to control and inspect traffic
between ers.
Consider using an SDN soluon inside the data center for an agile, virtualized infrastructure
that maximizes resource ulizaon and makes automaon and scaling easier.

STEP 5 | Plan to use best pracce methodology to inspect all data center traffic and gain complete
visibility, reduce the aack surface, and prevent known and unknown threats.
Posion physical or virtual firewalls where they can see all data center network traffic.
Take advantage of the firewall’s powerful toolset to create applicaon-based Security policy
rules ed to specific user groups and protected by Security profiles. Forward unknown

Data Center Best Pracce Security Policy Version Version 10.1 7 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

files to WildFire and deploy decrypon to prevent threats from entering the data center in
encrypted traffic.
Use GlobalProtect in internal mode as a gateway to control data center access.
Authencate users to prevent unauthorized access and configure Mul-Factor
Authencaon for access to sensive applicaons, services, and servers, especially by
contractors, partners, and other third-pares who require access to your data center.
Manage firewalls centrally with Panorama to enforce consistent policy across physical and
virtual environments and for centralized visibility.
If you have mulple data centers, reuse templates and template stacks to apply consistent
security policy across different locaons.

STEP 6 | Phase in your best pracce deployment over me; start by focusing on the most likely
threats to your business and network, and protect your most valuable assets first.
Taking into account all of the data center users, applicaons, devices, and traffic flows, and
then creang best pracce Security policy around them may seem like an overwhelming task
if you try to do everything at one me. But by protecng your most valuable assets first and
planning a phased, gradual implementaon, you can transion in a smooth and praccal way
from a hope-for-the-best Security policy to a best pracce Security policy that safely enables
applicaons, users, and content.

Data Center Best Pracce Security Policy Version Version 10.1 8 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

Deploy Data Center Best Pracces


Implement data center best pracces when you create Security profiles, Decrypon profiles,
Security policy rules, Authencaon policy rules, and Decrypon policy rules.

For Security, Authencaon, and DoS policy rules, configure log forwarding to
Panorama or external services to centralize logs for convenient viewing and analysis, with
noficaons.

• Global Data Center Objects, Policies, and Acons


• User Data Center Traffic Policies
• Internet-to-Data-Center Traffic Policies
• Data-Center-to-Internet Traffic Policies
• Intra-Data-Center Traffic Policies
• Data Center Security Policy Rulebase Order

Global Data Center Objects, Policies, and Acons


Ensure that you can protect custom applicaons if you use them. Configure Security profiles and
Decrypon profiles and install Cortex XDR Agent on all data center endpoints.
• Custom Applicaons
• Security Profiles
• Decrypon Profiles
• Traffic Blocking Rules
• Install Cortex XDR Agent on Endpoints
STEP 1 | If your data center applicaon inventory includes proprietary custom applicaons, then
create custom applicaons for them so that you can specify them in Security policy.

STEP 2 | Configure ght data center best pracce Security profiles to prevent threats from disrupng
your data center network.
Configure the best pracce Anvirus profile by cloning the predefined profile and changing
the imap, pop3, and smtp decoder values to reset-both in the Acon and WildFire Acon
columns.
Configure the best pracce An-Spyware profile by cloning the predefined strict profile. On
the Rules tab, enable single packet capture on medium, high, and crical severity threats
for traffic you log. (For traffic you don’t log, apply a separate profile without packet capture
enabled.)
On the DNS Signatures tab, change the Acon on DNS Queries to sinkhole if the firewall
can’t see the originator of the DNS query (typically when the firewall is north of the local
DNS server) so that you can idenfy infected hosts. DNS sinkhole idenfies and tracks
potenally compromised hosts that aempt to access suspicious domains and prevents

Data Center Best Pracce Security Policy Version Version 10.1 9 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

them from accessing those domains. Enable extended packet capture on the sinkholed
traffic.
Configure the best pracce Vulnerability Protecon profile by cloning the predefined
strict profile and changing the Packet Capture seng for every rule except simple-client-
informaonal and simple-server-informaonal to single-packet. If the firewall idenfies a
large volume of vulnerability threats and that affects performance, disable packet capture
for low-severity events.
The predefined strict File Blocking profile is the best pracce profile. If supporng crical
applicaons prevents you from blocking all the file types the strict profile blocks (you can
idenfy the file types used in the data center from data filtering logs at Monitor > Logs >
Data Filtering), clone the strict profile and modify it as needed. If files don’t need to flow
in both direcons, use the Direcon seng to restrict the file type to only the required
direcon.
The predefined WildFire Analysis profile is the best pracce profile. WildFire provides the
best defense against unknown threats and advanced persistent threats (ATPs).

STEP 3 | Configure ght data center best pracce Decrypon profiles to prevent unknown traffic from
entering your data center.
Perform CRL/OCSP checks to ensure that cerficates presented during SSL decrypon are
valid.
SSL Protocol Sengs: Set the Min Version to TLSv1.2, the Max Version to Max, and
uncheck the SHA1 Authencaon Algorithm. (The weak 3DES and RC4 Encrypon
Algorithms are automacally unchecked when you select TLSv1.2.) Use TLSv1.3 for traffic
that supports TLSv1.3 (many mobile applicaons use cerficate pinning, which prevent
decrypon when using TLSv1.3, so for these applicaons, use TLSv1.2).
SSL Forward Proxy: For Server Cerficate Verificaon, block sessions with expired
cerficates, untrusted issuers, and unknown cerficate status, and restrict cerficate
extensions. For Unsupported Mode Checks, block sessions with unsupported versions,
unsupported cipher suites, and client authencaon. For Failure Checks, blocking sessions
if resources aren’t available is a tradeoff between the user experience (blocking may
negavely affect the user experience) and potenally allowing dangerous connecons.
If you have to consider this tradeoff, also consider increasing the decrypon resources
available in the deployment.
SSL Inbound Inspecon: For Unsupported Mode Checks, block sessions with unsupported
versions and unsupported ciphers. For Failure Checks, the tradeoffs are similar to SSL
Forward Proxy.
SSH Proxy: For Unsupported Mode Checks, block sessions with unsupported versions and
unsupported algorithms. For Failure Checks, the tradeoffs are similar to SSL Forward Proxy.
Apply the No Decrypon profile to traffic you choose not to decrypt because of regulaons,
compliance rules, or business reasons, except TLSv1.3 traffic (TLSv1.3 encrypts cerficate
informaon, so the firewall cannot block traffic based on cerficate informaon). Block
sessions with expired cerficates and untrusted issuers.

Data Center Best Pracce Security Policy Version Version 10.1 10 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

STEP 4 | Configure traffic blocking rules to deny traffic you know is malicious or isn’t needed for
business purposes.
Logging and monitoring block rules may reveal users and applicaons you didn’t know were
on your network and that may be legimate or may indicate an aack. The rule order in the
Security policy rulebase is crical to prevent shadowing (traffic matching an allow or block rule
before it can match the rule you intend the traffic to match). Some rules are almost the same
but enable separate reporng for standard and non-standard ports or for user applicaons and
applicaons from other sources. For each rule, configure Log at Session End on the Acons tab
and set up Log Forwarding to track and analyze rule violaons.
Block all applicaons from user zones on the applicaon-default port. Place this rule aer
the rules that allow legimate applicaon traffic from user zones to idenfy unknown or
unexpected user applicaons on standard ports.

Block all applicaons from user zones on any port to catch user traffic aempng to use
non-standard ports. Place this rule aer the preceding applicaon-default block rule to
idenfy unknown or unexpected user applicaons on non-standard ports, which may be
custom applicaons or evasive applicaons.

Block applicaons you never want in your data center, such as evasive and commonly
exploited applicaons and applicaons not required for business. Place this rule aer the
applicaon allow rules so that, for example, you allow sanconed file sharing applicaons
before the Filesharing applicaon filter blocks all other file sharing applicaons.

Block all applicaons from any zone on the applicaon-default port to idenfy unexpected
applicaons on standard ports. Rule matches may indicate potenal threats or applicaon

Data Center Best Pracce Security Policy Version Version 10.1 11 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

changes that require modifying an allow rule. Place this rule aer the applicaon allow rules
and the preceding block rule.

Block all applicaons from any zone on any port to idenfy unexpected applicaons on
non-standard ports. Don’t allow unknown-tcp, unknown-udp, or non-syn-tcp traffic. Place
this rule aer the applicaon allow rules and the preceding block rule.

Block unknown users aempng to run applicaons on any port to discover unknown
users (gaps in User-ID coverage or aackers) and idenfy compromised devices (including
embedded devices such as printers, card readers, and cameras). Place this rule aer the
applicaon allow rules and the preceding block rule.

In addion to blocking unwanted potenally malicious traffic, block Quick UDP Internet
Connecons (QUIC) protocol, unless for business reasons, you want to allow encrypted
browser traffic. Chrome and some other browsers establish sessions using QUIC instead
of TLS, but QUIC uses proprietary encrypon that the firewall can’t decrypt, so potenally
dangerous traffic may enter the network as encrypted traffic. Block both the QUIC
applicaon and UDP ports 80 and 443 to force the browser to use TLS. First create a
Service (Objects > Services) that includes UDP ports 80 and 443:

Use the Service to specify the UDP ports to block for QUIC. In the second rule, block the
QUIC applicaon so that the first two rules in your rulebase block QUIC:

STEP 5 | Install Cortex XDR Agent on all data center endpoints to protect against malware and
exploits on the endpoints.
Cortex XDR Agent protects all endpoints the same way, so the deployment process and
malware protecon policy best pracces are the same for the data center as for any other
network area.

Data Center Best Pracce Security Policy Version Version 10.1 12 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

User Data Center Traffic Policies


Configure Security policy, Authencaon policy, and Decrypon policy for users who need to
access the data center.
• User Security Policy Rules
• User Authencaon Policy Rules
• User Decrypon Policy Rules
STEP 1 | Create applicaon allow list Security policy rules for user traffic to allow appropriate access.
Place allow rules for user access at the top of the rulebase, before block rules, to prevent
accidentally blocking legimate traffic. For each rule, configure Log at Session End on the
Acons tab and set up Log Forwarding to track and analyze rule violaons.
Enable employee user access to internal corporate DNS servers. This rule allows any user
because users access DNS services before they log in. The rule ghtly controls the source
zone, desnaon servers, and applicaon, and applies Security profiles to the traffic.

Block access to external DNS servers at the internet gateway to prevent DNS traffic
from going out on the internet to public servers.

Allow secured, privileged access to data center management interfaces for the necessary
IT personnel. Restrict the rule to management interfaces (this example uses an address
group to idenfy the devices and a custom service to idenfy the management ports) and
the necessary applicaons, in this example, RDP, SSH, and SSL. Use a dedicated VLAN to

Data Center Best Pracce Security Policy Version Version 10.1 13 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

separate management traffic from other traffic and place management interfaces on the
same subnet.

If the same IT user group also manages switches, routers, and other data center
devices, add them to the desnaon and add their ports to the custom service so
the rule secures traffic for connecons to their management interfaces. If different
IT groups manage different data center resources, create separate Security policy
rules and corresponding Decrypon and Authencaon policy rules for each group.

Allow required access for employee user groups. These rules limit each user group’s (or
user’s) access to the necessary applicaons and servers. This example limits an engineering
user group’s access to only its development servers and applicaons.

Allow targeted, limited access to contractors, partners, customers, and other third-pares.
This example limits access for an SAP contractor group so the group can reach only the
appropriate SAP database servers, using only the appropriate applicaons.

STEP 2 | Create Authencaon policy rules for user traffic to authencate data center access.
For each user group or user for whom you create applicaon allow rules, create an analogous
authencaon rule (except the DNS allow rule because DNS occurs before users authencate
to log in). For each rule, configure Log at Session End on the Acons tab and set up Log
Forwarding to track and analyze rule violaons.
Authencate users who need specialized access. This example authencates the IT
personnel who need secure privileged access to manage data center servers from the
preceding step’s allow rule. Because compromising the credenals of a privileged user hands

Data Center Best Pracce Security Policy Version Version 10.1 14 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

an aacker the keys to your data center kingdom, require Mul-Factor Authencaon
(MFA) to protect against stolen credenals.

If the same IT user group also manages switches, routers, and other data center
devices, add them to the desnaon and add their ports to the custom service so
the rule authencates traffic for connecons to their management interfaces. If
different IT groups manage different data center resources, create separate Security
policy rules and corresponding Decrypon and Authencaon policy rules for each
group.

Authencate employees with legimate business reasons to access the data center. This
example authencates the engineering development user group from the preceding step’s
allow rule.

Authencate contractors, partners, customers, and other non-employee groups. Require


MFA for non-employee groups to protect against credenal the at a third-party company.
This example authencates the SAP developers from the preceding step’s allow rule.

STEP 3 | Create Decrypon policy rules for user traffic to decrypt traffic you allow so the firewall can
see, inspect, and apply Security policy to the traffic.
For each Decrypon policy rule, apply the appropriate best pracce Decrypon profile (SSL
Inbound Inspecon, SSL Forward Proxy, SSH Proxy, or No Decrypon, including best pracce
SSL Protocol Sengs for SSL Inbound Inspecon and SSL Forward Proxy rules) to block weak
protocols and algorithms and to verify server cerficates. For each SSL Inbound Inspecon
rule, import the cerficate of the of the data center server you are protecng with decrypon.

Exclude traffic from decrypon only for these two reasons:


• Traffic breaks decrypon for technical reasons, such as a pinned cerficate or
mutual authencaon. Add technical exclusions to the Device > Cerficate
Management > SSL Decrypon Exclusion list.
• Traffic that you choose not to decrypt because of business, regulatory, compliance,
or other reasons, such as financial, health, or government traffic. Create policy-
based decrypon exclusions for traffic you choose not to decrypt.

Decrypt traffic from the previously created Security policy rule that allows IT privileged
access to management servers. The Decrypon policy rule and its associated Decrypon

Data Center Best Pracce Security Policy Version Version 10.1 15 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

profile differ depending on whether the IT group uses SSL (SSL Forward Proxy Decrypon
profile) or SSH (SSH Proxy Decrypon profile) to access management ports.

If the same IT user group also manages data center switches, routers, and other
devices, add them to the desnaon and add the server cerficates so the rule
decrypts traffic for connecons to their management interfaces. If different IT
groups manage different sets of data center resources, create separate, ght
Security policy rules and corresponding Decrypon and Authencaon policy rules
for each group.

For SSL privileged access:

For SSH privileged access:

Configure SSL Inbound Inspecon to decrypt allowed traffic from employee user groups.
This example decrypts traffic from the analogous engineering development user group allow
rule.

Configure SSL Inbound Inspecon to decrypt allowed traffic from contractors, partners,
customers, and other third-pares. This example decrypts traffic from the analogous SAP
contractor user group allow rule.

Apply a No Decrypon profile to configure server verificaon for traffic that you choose not
to decrypt because of business, regulatory, compliance, or other reasons, such as financial,
health, or government traffic. This example shows how to exclude two groups of finance
users from decrypon when they access servers in the Fin Servers address group.

Do not apply a No Decrypon profile to TLSv1.3 traffic because the cerficate


informaon is encrypted, so the firewall cannot block sessions based on cerficate
informaon.

Data Center Best Pracce Security Policy Version Version 10.1 16 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

Internet-to-Data-Center Traffic Policies


Configure Security policy, Decrypon policy, and Denial-of-Service (DoS) Protecon policy for
traffic from the internet to the data center.
• Internet-to-Data-Center Security Policy
• Internet-to-Data-Center Decrypon Policy
• Internet-to-Data-Center DoS Protecon Policy
STEP 1 | Create applicaon allow list Security policy rules for internet-to-data-center traffic to control
and secure partner, contractor, and customer access.
Protect against downloading malware from an infected external client or placing malware on an
external server from an infected data center server. Create allow rules for applicaons required
for business purposes and create an External Dynamic List (EDL) to block bad IP addresses. For
each rule, configure Log at Session End on the Acons tab and set up Log Forwarding to track
and analyze rule violaons.
This example restricts the applicaons and desnaons for internet-to-data-center traffic, and
uses the Negate opon to prevent communicaon with the Bad IPs List EDL.

Create similar rules for traffic from the internet to other server groups (if allowed) and other
applicaons. Make each rule specific to limit access to only the required applicaons and
servers.

STEP 2 | Create Decrypon policy rules for internet-to-data-centertraffic to decrypt allowed traffic.
Configure SSL Inbound Inspecon (and import the desnaon server cerficates into the
firewall) to decrypt partner, contractor, and customer traffic that Security policy rules allow for
internet-to-data-center traffic. This example shows the Decrypon policy for the preceding
Security policy rule.

Create Decrypon rules to match traffic that internet-to-data-center Security policy rules
allow.

STEP 3 | Create internet-to-data-center DoS Protecon policy rules to protect sensive servers from
Denial-of-Service (DoS) aacks by liming the number of connecons-per-second (CPS) the
firewall allows to the servers to prevent a SYN flood aack.
Aackers target the web server er because if they take it down, they prevent most legimate
access to the data center. Apply a classified DoS Protecon policy rule with a DoS Protecon

Data Center Best Pracce Security Policy Version Version 10.1 17 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

profile that limits the incoming CPS to prevent traffic spikes that can affect server performance
and availability.
Create a classified DoS Protecon profile to protect the web server er and prevent SYN
flood aacks. The CPS thresholds you set depend on the baseline peak CPS rate.

Create a DoS Protecon policy rule to specify the web servers you’re protecng and apply
the classified DoS Protecon profile to it.

To protect against SYN flood aacks from internal sources, create a separate DoS Protecon
policy rule that specifies your internal zones as the source zone instead of L3-External.
Separate rules for external and internal aack sources provides separate reporng that
makes invesgang aack aempts easier.
In addion, configure Packet Buffer Protecon for each data center zone to protect the
firewall from single-session DoS aacks that can cause legimate traffic to drop.

Data-Center-to-Internet Traffic Policies


Configure Security policy and Decrypon policy for traffic from the data center to the internet.
• Data-Center-to-Internet Security Policy
• Data-Center-to-Internet Decrypon Policy
STEP 1 | Create data-center-to-internet allow rules to protect connecons to external servers.
Data center servers may obtain soware updates or cerficate status from servers on the
internet. The greatest risk is connecng to the wrong server. Create strict allow rules for
updates to limit the reachable external servers and the allowed applicaons (on default ports
only). This prevents infected data center servers from phoning home and prevents data
exfiltraon using legimate applicaons such as FTP, HTTP, or DNS on non-standard ports. In

Data Center Best Pracce Security Policy Version Version 10.1 18 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

addion, use the File Blocking profile’s Direcon control to block outbound update files so you
only allow downloading for soware update files.
For each rule, apply best pracce Security profiles and configure Log at Session End on the
Acons tab.

Work with engineering and other groups that update soware to log and analyze web
browsing sessions to define the URLs to which developers connect for updates.

These examples allow engineering servers to communicate with CentOS update servers
(CentOS-Update-Servers custom URL Category) using the yum applicaon and with
Microso update servers (Win-Update-Servers custom URL Category) using the ms-update
applicaon (you must also allow ssl because ms-update has a dependency on SSL).

Allow access to DNS and NTP updates (NTP DNS Update Servers custom URL Category).

Allow connecng to an internet Online Cerficate Status Protocol (OCSP) Responder to


check the revocaon status of authencaon cerficates and ensure they are valid. When
you configure a cerficate profile on the firewall, set up CRL status verificaon as a fallback
method for OCSP in case the OCSP Responder is unreachable.

STEP 2 | Create data-center-to-internet Decrypon policy rules to decrypt the traffic allowed in the
preceding Security policy rules.
A compromised update server could download malware and propagate it through the soware
update process, so decrypng traffic to gain visibility is crical. Because only service accounts

Data Center Best Pracce Security Policy Version Version 10.1 19 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

iniate update traffic and update traffic has no personal or sensive informaon, there are no
privacy issues.

Don’t decrypt traffic to OCSP cerficate revocaon servers because the traffic usually
uses HTTP, so it’s not encrypted. In addion, SSL Forward Proxy decrypon may
break the update process because the firewall acts as a proxy and replaces the client
cerficate with a proxy cerficate, which the OCSP responder may not accept as valid.

Decrypt traffic between data center and update servers. These two examples decrypt the
CentOS and Windows update traffic allowed by the analogous Security policy rules in the
preceding step.

Decrypt traffic between data center servers and NTP and DNS update servers. This example
decrypts the update traffic allowed by the analogous Security policy rule in the preceding
step.

Intra-Data-Center Traffic Policies


Configure Security policy and Decrypon policy for traffic between data center servers and
applicaon ers.
• Intra-Data-Center Security Policy
• Intra-Data-Center Decrypon Policy
STEP 1 | Create intra-data-center applicaon allow rules to protect data center servers from other
data center servers that may be compromised.
A common applicaon architecture consists of three server ers: web servers, applicaon
servers, and database servers. Apply best pracce Security profiles to most traffic between
server ers to prevent threats. Don’t apply Security profiles to low-value, high-volume traffic
such as mailbox replicaon and backup flows—the firewall already inspected the original flows,
so spending CPU cycles on them provides no extra value. Do create allow rules for these

Data Center Best Pracce Security Policy Version Version 10.1 20 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

applicaons to prevent misuse. For each rule, configure Log at Session End on the Acons tab
and set up Log Forwarding to track and analyze rule violaons.
This example configures rules that allow traffic between applicaon server ers for two
proprietary internal finance applicaons for which we created custom applicaons: Billing-App
and Payment-App.
Allow finance applicaon traffic between the web server er and the applicaon server er.

Allow finance applicaon traffic between the applicaon server er and the database server
er.

STEP 2 | Create intra-data-center Decrypon policy rules to decrypt the traffic allowed in the
preceding Security policy rules.
The data center is a perfect place for aackers to hide because many people think the data
center is safe and don’t look for intruders. But the same basic tenet that’s true in the rest of
the network holds true in the data center: you can’t protect yourself against what you can’t
see. Decrypt encrypted data center traffic so that the firewall can inspect traffic, control access,
make threats visible, and protect your valuable assets.

Not all data center traffic is encrypted. Don’t spend resources to decrypt unencrypted
(cleartext) traffic.

• This rule decrypts traffic flowing between the web server er and the applicaon server er
for the Finance department’s billing servers.

• This rule decrypts the traffic flowing between the applicaon server er and the database
server er for the Finance department’s billing servers.

Data Center Security Policy Rulebase Order


Order the rules properly in the Security policy rulebase to ensure that you allow only the
applicaons and traffic you intend to allow and so that no rule shadows another rule.

Data Center Best Pracce Security Policy Version Version 10.1 21 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

Order the Data Center Security policy rulebase shows the full rulebase from the previous
examples (allow and block rules) in the correct order and explains each rule’s placement.

Data Center Best Pracce Security Policy Version Version 10.1 22 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

Follow Post-Deployment Data Center Best Pracces


Aer you begin deploying data center best pracces, monitor the network to ensure that security
and access are working as expected, and then maintain the rulebase as circumstances change.
STEP 1 | Check the predefined Applicaons report ( Monitor > Reports > Applicaon Reports >
Applicaons) to verify that only applicaons you allowed in Security policy rules are running.
If you find unexpected applicaons, review the Security policy rules and refine them to
eliminate unexpected applicaons or to accommodate legimate applicaons.

STEP 2 | Log all data center traffic.


Use Palo Alto Networks’ extensive monitoring tools, logging tools, predefined reports, and
custom reports to capture and monitor acvity for unexpected applicaons, users, traffic, and
behaviors.

STEP 3 | Create custom reports to monitor the block rules, which protect against potenal aacks and
also idenfy policy gaps and unexpected behaviors so you can tune the rulebase.

STEP 4 | Create a custom report to log intra-data-center traffic that matches the predefined intrazone-
default allow rule at the boom of the rulebase, which allows all traffic within the same zone
by default.

STEP 5 | Enable logging on and create a custom report for data center traffic that matches the
predefined interzone-default rule at the boom of the rulebase, which denies all traffic
between zones by default.

STEP 6 | Listen and respond to user feedback.


User complaints about losing access to applicaons idenfies gaps in the rulebase or risky
applicaons that were in use on your network before applicaon allow lisng prevented their
use.

STEP 7 | Periodically compare the baseline measurements you took during the planning stage to the
current measurements to evaluate progress, idenfy changes, and find areas of improvement.
At the same me, revisit your goal for the ideal future state of the network to assess progress.
If you manage firewalls with Panorama, monitor firewall health to compare devices to their
baseline performance and to each other to idenfy deviaons from normal behavior.

STEP 8 | Evolve applicaon allow rules over me because applicaons evolve, user requirements
change, and content updates modify exisng App-IDs and introduce new App-IDs.
Maintain the data center best pracce rulebase and review new and modified App-IDs before
you install a new content release so you can modify the rulebase if the changes impact policy.

STEP 9 | Use Palo Alto Networks assessment and review tools to assess your current prevenon
posture and your adopon of best pracces.

STEP 10 | Refer to the full Data Center Best Pracce Security Policy for details about each planning,
deployment, and post-deployment step and how they benefit you.

Data Center Best Pracce Security Policy Version Version 10.1 23 ©2021 Palo Alto Networks, Inc.
Data Center Security Policy Best Pracces Checklist

Data Center Best Pracce Security Policy Version Version 10.1 24 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security
Policy
Your enterprise’s most valuable assets reside in your data center, including proprietary
source code, intellectual property, and sensive company and customer data. Your
customers and employees trust you to maintain the confidenality of their sensive
data and expect your data center to be always available because they expect their
data to be always available. It’s important for the integrity and success of your
business to implement a data center best pracce security policy that safeguards your
data and prevents successful aacks.
The following methods and recommendaons provide a blueprint for planning,
designing, and implemenng a data center best pracce security policy in a phased,
priorized manner. Creang a data center best pracce security policy may be a
daunng task if you try to implement every protecon on every area of your network
at one me. However, if you evaluate what is most important to protect and begin
implemenng your data center best pracce security policy by defending your most
valuable assets first, you can transion gradually to a security policy that allows you to
safely enable applicaons, users, and content without taking undue risks.

The Data Center Security Policy Best Pracces Checklist provides an overview of pre-deployment,
deployment, and post-deployment best pracces, and a way to implement best pracces more
quickly if you don’t need detailed explanaons.

> What Is a Data Center Best Pracce > Create Data Center Traffic Block
Security Policy? Rules
> Why Do I Need a Data Center Best > Define the Inial User-to-Data-
Pracce Security Policy? Center Traffic Security Policy
> Data Center Best Pracce > Define the Inial Internet-to-Data-
Methodology Center Traffic Security Policy
> How Do I Deploy a Data Center Best > Define the Inial Data-Center-to-
Pracce Security Policy? Internet Traffic Security Policy
> How to Assess Your Data Center > Define the Inial Intra-Data-Center
> How to Decrypt Data Center Traffic Traffic Security Policy

> Create a Data Center Segmentaon > Order the Data Center Security
Strategy Policy Rulebase

> How to Create Data Center Best > Log and Monitor Data Center Traffic
Pracce Security Profiles > Maintain the Data Center Best
> Use Cortex XDR Agent to Protect Pracce Rulebase
Data Center Endpoints > Use Palo Alto Networks Assessment
and Review Tools

25
Data Center Best Pracce Security Policy

What Is a Data Center Best Pracce Security Policy?


A data center best pracce security policy protects your own company’s valuable data, protects
the confidenality of your customers, partners, and vendors, protects the integrity of your
network and business operaons as a whole, and helps ensure the constant availability of the
network. It protects against aacks that originate outside or inside the network, along all aack
vectors.
A data center best pracce security policy protects four traffic flows (areas from which
connecons are iniated):
1. Local user traffic flowing into the data center.
2. Traffic flowing from the internet to the data center.
3. Traffic flowing from the data center to the internet.
4. Intra data center traffic flowing between servers or VMs, also known as east-west traffic.
A data center best pracce security policy prevents aackers from gaining a foothold in your data
center and prevents any aacker who manages to breach the data center from exfiltrang data or
moving laterally within the network to compromise crical servers. It prevents both known and
unknown threats by implemenng security policy rules to achieve best-pracce goals that are
aligned with your business requirements. It:
• Idenfies applicaons regardless of port, protocol, or evasive technique, including by
decrypng encrypted traffic.
• Idenfies and controls users regardless of IP address, locaon, or device.
• Protects against known and unknown applicaon-borne threats and vulnerabilies.
• Detects abnormal behavior that may indicate an aack is in progress.
A data center best pracce security policy also catches intruders when they violate a policy rule.
Violang a rule stops the aack because the violaon causes the next-generaon firewall to deny
access and logs the violaon so you can invesgate the issue and take appropriate acon.

Data Center Best Pracce Security Policy Version Version 10.1 26 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Why Do I Need a Data Center Best Pracce Security


Policy?
Protecng the availability, confidenality, and integrity of your network so that you can run
your business securely, without interrupon, and in compliance with regulaons governing the
protecon of sensive data, is crical. The idea that hardening the exterior of the network and
allowing the interior of the network to remain so because the interior is trusted is outdated,
leaves the network open to aack from the inside, and doesn’t plan for a scenario in which a
determined, resourced, persistent aacker finds a foothold inside the perimeter. That’s why you
need to protect the data center perimeter and interior as strongly as you protect the enterprise
network perimeter.
Inside aacks can originate from sources such as current employees or on-site contractors. The
common thread in inside aacks is that the aack comes from a legimate user or applicaon
source. Outside aacks can originate from cyber-criminals, hackvists, and state-sponsored
aackers, and from less obvious avenues of aack such as compromised partner or vendor
systems, or a former employee who knows the network. The first step for an outside aacker is
to gain a foothold inside the network, transforming the aack to an inside aack. In essence, all
breaches are inside aacks even if they originate on the outside, because once an aacker gains
access to the network, the aacker can roam throughout the network.

If an aacker steals the legimate access credenals of a partner, the aacker can access your
data center disguised as a legimate user. Then, from the “so, chewy interior” of your network,
the aacker can use your internal servers and endpoints to move laterally through the network
and compromise crical systems. Once an outside adversary breaches the network, you rely on
network and user segmentaon and layered defenses inside the network to protect your data, the
same as when an aack originates from the inside.
Developing a best pracce security policy helps protect your data center from aacks regardless
of origin, in a staged and priorized manner, securing the most valuable assets first and then

Data Center Best Pracce Security Policy Version Version 10.1 27 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

phasing in addional protecon. A gradual transion from a hope-for-the-best security policy


to a best pracce security policy helps to ensure the confidenality of your data, the integrity
of your organizaon, and the availability of the data center in a praccal way. The following
recommendaons for designing and implemenng a data center best pracce security policy show
you how to safely enable applicaons, users, and content by classifying all traffic, all the me, with
minimal disrupon to end users.

Data Center Best Pracce Security Policy Version Version 10.1 28 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Data Center Best Pracce Methodology


The following best pracce methodologies ensure detecon and prevenon at mulple stages of
the aack life cycle.

Best Pracce Why Is This Important?


Methodology

Inspect All Seeing network traffic enables you to idenfy the presence of aackers.
Traffic to Gain Inspect traffic to see the users, applicaons, and content that flow into,
Complete through, and out of the data center:
Visibility
Deploy next-generaon firewalls in posions where they can inspect all
of the network traffic. Don’t allow traffic to flow into the data center or
between network segments without posioning a firewall to examine the
traffic.
Enable SSL decrypon on all traffic entering or exing the data center,
unless regulaons or compliance rules require you to except categories
such as health, finance, government, or military. You must see threats to
protect your network against them. Because more than 50 percent of a
typical network’s traffic is encrypted and that percentage is rising, if you
don’t decrypt traffic, you can’t completely protect your network.
Use App-ID to idenfy applicaons, and create custom applicaons for
proprietary applicaons, so that the firewall can idenfy and categorize
those applicaons appropriately and apply the correct security policy rule.
This is especially important for older legacy applicaons that are otherwise
categorized as “web-browsing” or “unknown-tcp” instead of being correctly
categorized.
If you have exisng Applicaon Override policies that you created solely
to define custom session meouts for a set a of ports, convert the exisng
Applicaon Override policies to applicaon-based policies by configuring
service-based session meouts to maintain the custom meout for each
applicaon and then migrang the rule the an applicaon-based rule.
Applicaon Override policies are port-based. When you use Applicaon
Override policies to maintain custom session meouts for a set of ports,
you lose applicaon visibility into those flows, so you neither know nor
control which applicaons use the ports. Service-based session meouts
achieve custom meouts while also maintaining applicaon visibility.
Enable User-ID on all traffic entering or exing the data center to map
applicaon traffic and associated threats in its content to users and
services. You enable User-ID on network segments (zones), so you must
segment the network to enable User-ID. Segmenng the network is a best
pracce for gaining visibility and reducing the aack surface.
Deploy GlobalProtect in internal mode as a gateway to control access to
the data center. GlobalProtect checks user informaon to verify users, and
host informaon to verify that host security is up-to-date, by comparing
the host informaon to HIP objects and profiles that you define. This

Data Center Best Pracce Security Policy Version Version 10.1 29 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Best Pracce Why Is This Important?


Methodology
ensures that hosts connecng to your network maintain your level of
security standards.
Enable “log at session end” on all security policy rules.
Visibility into traffic enables the firewall to use its nave App-ID, Content-
ID, and User-ID technologies to e the applicaons, threats, and content to
users, regardless of user locaon or device type, port, encrypon, or evasive
technique.

Reduce the The aack surface is all of the points of network interacon, both hardware
Aack Surface and soware, including applicaons, content, and users, along with servers,
switches, routers, and other physical and virtual equipment. Reducing the
aack surface leaves fewer vulnerabilies for aackers to target. The more
you reduce the aack surface, the harder it is to breach the network.
Assess your data center so that you know the applicaons, content, and
users on the network.
Use posive security enforcement by creang applicaon-based security
policy rules that allow only applicaons with a legimate business use
on the network and rules to block all high-risk applicaons that have no
legimate use case.
Use the informaon from assessing the environment to create a strategy
that segments the network into zones based on business requirements,
common funconality, and global policy requirements, so that the
resources in each zone need the same security level. Inside the data center,
segment applicaons ers such as databases, web servers, applicaon
servers, development servers, and producon servers into zones.
Segmentaon enables you to see traffic between different applicaon ers
because the traffic must traverse a firewall when it flows between zones.
Granular segmentaon enables you to construct security policy rules
that focus on the business requirements of each zone and provide the
appropriate protecon to each segment. Segmentaon also helps stop
lateral movement of malware into and within the data center because the
combinaon of App-ID, Content-ID (threat prevenon), and User-ID enable
you to idenfy the traffic that should be allowed access and deny the rest.
Deploy GlobalProtect in internal mode as a gateway to control access to
the data center.
To further reduce the aack surface, on security policy rules that allow
applicaon traffic, apply File Blocking profiles to block malicious and
risky file types. Prevent credenal the breaches by using the firewall’s
authencaon policy to enable Mul-Factor Authencaon, so that even
if aackers succeed in stealing credenals, they won’t succeed in accessing
the data center network.

Data Center Best Pracce Security Policy Version Version 10.1 30 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Best Pracce Why Is This Important?


Methodology

Prevent Security profiles aached to security policy allow rules scan traffic for known
Known threats such as viruses, spyware, applicaon-layer vulnerability exploits,
Threats malicious files, and more. The firewall applies an acon such as allow, alert,
drop, block IP, or a connecon reset to those threats based on the security
profile configuraon.
Follow content update best pracces and install content updates as soon as
possible aer downloading them to update the security profiles and apply
the latest protecons to your data center. Security profiles are fundamental
protecons that are easy to apply to security policy rules.
External dynamic lists (EDLs) also protect against known threats. EDLs
import lists of malicious and risky IP addresses, URLs, or domains into the
firewall to prevent known threats. EDLs come from trusted third pares, from
predefined EDLs on the firewall, and from custom EDLs that you create. EDLs
are updated dynamically on the firewall without requiring a commit.
Prevenng known threats is another reason that enabling decrypon is
important. If you can’t see the threat, it doesn’t maer if you know about it,
you may sll be vicmized because you can’t see it.

Prevent How do you detect a threat nobody has seen before? The answer is to
Unknown forward all unknown files to WildFire for analysis.
Threats
WildFire idenfies unknown or targeted malware. The first me a firewall
detects an unknown file, the firewall forwards the file to its internal
desnaon and also to the WildFire cloud for analysis. WildFire analyzes
the file (or a link in an email) and returns a verdict to the firewall in as lile
as five minutes. WildFire also includes a signature that idenfies the file,
transforming the unknown file to a known file. If the file contained a threat,
the threat is now known. If the file is malicious, the next me the file arrives
at the firewall, the firewall blocks it.
You can check verdicts in the WildFire submission logs (Monitor > Logs
> WildFire Submissions). Set up WildFire appliance content updates to
download and install automacally every minute so that you always have the
most recent support. For example, support for Linux and SMB files were first
delivered in WildFire appliance content updates.

In addion:
Manage firewalls centrally with Panorama to consistently enforce policy across physical and
virtual environments and for centralized visibility.
Use posive security enforcement to allow traffic you want on your data center network and
deny the rest.
Create a standardized, scalable design that you can replicate and apply consistently across data
centers.
Get buy-in from execuves, IT and data center administrators, users, and other affected pares.

Data Center Best Pracce Security Policy Version Version 10.1 31 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Phase in next-generaon security by focusing on the most likely threats to your parcular
business and network, and then determine the most important assets to protect and protect them
first. Ask the following quesons to help priorize the assets to protect first:
1. What makes our company what it is? What properes define and differenate your company,
and what assets map to those properes? Assets that relate to your company’s proprietary
compeve advantages should be high on the protecon priority ladder. For example, a
soware development company would priorize its source code, or a pharmaceucal company
would priorize its drug formulas.
2. What keeps the enterprise in business? Which systems and applicaons do you need to support
the daily operaon of the company? For example, your acve directory (AD) service provides
employee access to applicaons and workstaons. Compromising your AD service gives an
aacker access to all accounts within your enterprise, which gives the aacker full access
your network. Other examples include crical IT infrastructure such as management tools and
authencaon servers, and servers that house the most crical data for business operaons.
3. If I lost this asset, what would happen? The worse the consequences of losing an asset, the
higher the priority to protect that asset. For example, the user experience may differenate
a service company, so protecng that experience is high priority. Proprietary processes and
equipment may differenate a manufacturing company, so protecng the intellectual property
and proprietary designs is high priority. Create a priority list to define what to protect first.
Define the ideal future state of your data center network and work in phases to achieve it.
Periodically revisit your definion to account for changes in your business, new regulatory and
legal requirements, and new security requirements.

Data Center Best Pracce Security Policy Version Version 10.1 32 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

How Do I Deploy a Data Center Best Pracce Security


Policy?
The workflow for implemenng a data center best pracce security policy is to learn about your
data center network, its assets, and the firewall’s threat prevenon capabilies, and then create
inial security policy rules based on that informaon, protecng your most valuable assets first.
How to Assess Your Data Center—Idenfy and priorize the assets to protect, the biggest
threats to those assets, and the applicaons and users sanconed for access.
How to Decrypt Data Center Traffic—You can’t protect your network against threats you can’t
see. Encrypted traffic is a common method for aackers to deliver threats.
Create a Data Center Segmentaon Strategy—Segmenng your data center prevents an
adversary who gains a foothold in the data center from moving laterally to other areas.
How to Create Data Center Best Pracce Security Profiles—Legimate applicaons can
deliver command and control malware, common vulnerabilies and exposures (CVEs), drive-
by downloads of malicious content, phishing aacks, and APTs. Best pracce Security Profiles
protect allowed traffic from known and unknown threats for all four data center traffic flows.
Use Cortex XDR Agent to Protect Data Center Endpoints—Firewalls protect against threats that
traverse the network. But threats that execute on an endpoint don’t cross the network, so they
don’t traverse a firewall. Install Cortex XDR Agent on every endpoint to protect against threats
on the endpoints themselves.
Create Data Center Traffic Block Rules—Block known malicious IP addresses, applicaons that
aackers commonly exploit, applicaons designed to evade or bypass security, and applicaons
that you don’t need for business purposes in the data center.
Define the Inial User-to-Data-Center Traffic Security Policy—Unauthorized access poses a
huge risk to the valuable informaon inside the data center. Because employees and other
users on the internal corporate network are oen trusted, security precauons may be lax.
The user populaon and the data center may even be on one flat network. Tightly control who
can access the data center, the assets different user groups can access, and the level of access
different user groups have to applicaons.
Define the Inial Internet-to-Data-Center Traffic Security Policy—Protect data center servers
from malicious internet traffic. Exploing server-side vulnerabilies opens the data center to
aack and puts partners at risk because a compromised data center server could serve exploits
to third-party clients.
Define the Inial Data-Center-to-Internet Traffic Security Policy—Command-and-control
malware hiding on an infected internet-connected server can use legimate applicaons to
download more malware. Prevent applicaons from using non-standard ports, permit transfers
of only the file types that each applicaon should legimately use, and block URL categories
for malware, phishing, proxy anonymizer, peer-to-peer, and other potenally malicious URL
categories.
Define the Inial Intra-Data-Center Traffic Security Policy (East-West Traffic)—Threats from
within the data center are oen overlooked because no user traffic originates there and
within the data center is considered as trusted. However, if an aacker compromises a data
center server, communicaon between servers and VMs can spread malware. The best

Data Center Best Pracce Security Policy Version Version 10.1 33 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

pracce Security policy prevents aackers from moving laterally through the data center and
compromising more systems or exfiltrang data.
Log and Monitor Data Center Traffic— Logging and monitoring allowed and blocked traffic
provides informaon at all stages of the transion to and maintenance of your data center best
pracce security policy. It reveals the applicaons, users, and traffic paerns on your network,
including those you may not have known were there. This informaon helps you invesgate
potenal security issues.
Maintain the Data Center Best Pracce Rulebase—Connually monitor your applicaon
allow list so that you can adapt your rules to accommodate new sanconed applicaons and
determine how new or modified App-IDs impact your policy.
Order the Data Center Security Policy Rulebase summarizes the Security policy rulebase.

Data Center Best Pracce Security Policy Version Version 10.1 34 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

How to Assess Your Data Center


To achieve a Zero Trust security model, you need to know and evaluate the assets in your data
center so that you can priorize protecng the most valuable assets first, determine who should
have access to those assets, and understand the major risks to those assets. Understanding the
users who access the assets, the allowed applicaons, and the network itself enables you to
evaluate what you need and what you trust, so that you can cra a data center best pracce
security policy that allows only user access and applicaons that have legimate business
purposes on the network.
1. Inventory the data center environment—Inventory the physical and virtual data center
environments, including servers, routers, switches, security devices, and other network
infrastructure, and inventory the data center applicaons (including internally developed
custom applicaons) and service accounts.
• Assess each system based on its role in the network and its importance to the business
to priorize which porons of the physical and virtual infrastructure to protect first. For
example, if your business involves credit card transacons, the servers that handle credit
card transacons and the path of communicaon for traffic carrying credit card informaon
are extremely valuable assets whose protecon should be priorized.
• Examine at least 90 days of traffic logs to inventory the applicaons on the data center
network. Create a custom report based on the data center’s applicaon database to help
idenfy the exisng data center applicaons. Use the data center applicaon inventory to
develop an allow list of applicaons you want to sancon or tolerate on your data center
network, including internally developed custom applicaons.

Your inial applicaon inventory doesn’t need to idenfy every applicaon because
by monitoring the block rules that you configure for the data center best pracce
security rulebase, you’ll discover the applicaons you haven’t idenfied. Focus
on inventorying the applicaons and applicaon types that you want to allow.
When you finish developing the applicaon allow list, all applicaons that you don’t
explicitly allow are denied.

Map the applicaons to business requirements. If an applicaon doesn’t map to a business


requirement, evaluate whether you should tolerate it on the network. Applicaons that meet
no apparent business need increase the aack surface and may be part of an aacker’s tool
set. Even if an unneeded applicaon is innocent, the best pracce is to remove it so that
there is one less surface for an aacker to exploit. If mulple applicaons perform the same
funcon, for example, file sharing or instant messaging, consider standardizing on one or
two applicaons to reduce the aack surface.
If any internal custom applicaons don’t use the applicaon-default port, note the ports
and services required to support the custom applicaon. Consider rewring internal custom
applicaons to use the applicaon-default port.
Create groups for applicaons that require similar treatment on the network so that you
apply security policy efficiently to applicaon groups rather than to individual applicaons.
Applicaon groups make designing and implemenng security policy easier because you
can apply policy to all of the applicaons in a group at one me, change policy for the
enre group, add new applicaons to the group to apply the group’s policy to the new

Data Center Best Pracce Security Policy Version Version 10.1 35 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

applicaons, and reuse an applicaon group in mulple security policy rules. For example,
an applicaon group designed for data center storage applicaons may include applicaons
such as crashplan, ms-ds-smb, and NFS.
• Inventory the service accounts that applicaons use to communicate between servers and
within servers inside the data center. A best pracce is to use one service account for each
funcon instead of using one service account for mulple funcons. This limits access to
the service account and makes it easier to understand how the service account was used if a
system is compromised. Another best pracce is to idenfy service accounts that are hard-
coded into the applicaon so that you can write IPS signatures against them and monitor
the use of the accounts.
2. Characterize data center traffic—Characterize and map data center traffic to understand how
data flows across your network and between users and resources. Engage a cross-funconal
team that includes applicaon architects, network architects, enterprise architects, and
business representaves. Characterizing the traffic flows informs you about network traffic
sources and desnaons, typical traffic paerns and loads, and helps you understand the
traffic on your network and priorize the most important traffic to protect. Use Applicaon
Command Center widgets, Panorama’s firewall health monitoring features, and other methods
to understand the normal (baseline) traffic paerns, which helps you understand abnormal
traffic paerns that may indicate an aack.
3. Assess data center segmentaon—Segment data center server ers so that communicaon
between different server ers must pass through the next-generaon firewall to be decrypted,
examined, and protected by the best pracce security policy, and so that communicaon from
the user populaon or the internet passes through a next-generaon firewall. Outside the
data center, understand which zones can communicate with each data center zone, and then
determine which zones should be allowed to communicate with each data center zone.
4. Assess user populaon segmentaon and determine who should have access to the data
center—Map users to groups to segment the user populaon so that you can more easily
control access to sensive systems. For example, users in the Product Management group
should not be able to access finance or human resource systems. In Acve Directory (or
whatever system you use), create granular groups of users based on the access level the
users require for legimate business purposes so that you can control access to systems and
applicaons. This includes different employee groups as well as different contractor, partner,
customer, and vendor groups, grouped by the level of access needed.
Reduce the aack surface by creang user groups based on access requirements rather than
just funconality, and grant only the appropriate level of applicaon access to each group.
Within a funconal area such as Markeng or Contractors, create mulple user groups mapped
to applicaon access requirements.
5. Connuously monitor the data center network—Log and Monitor Data Center Traffic to reveal
gaps in the data center best pracce security policy, to expose unusual traffic paerns or
unexpected access aempts that may indicate an aack, and to diagnose applicaon issues.
A helpful method for evaluang assets is grouping assets. Idenfy your most valuable assets that
need to be protected first, and idenfy the assets that you can iterate on aer protecng those
assets. Priorize the order in which to protect the assets in each category. Organize assets in the
way that makes the most sense for your parcular business. The following table shows you some
possibilies, but it’s not comprehensive. Also consider legal compliance requirements to protect
data such as passwords, personal informaon, and financial informaon when priorizing which
assets to protect first.

Data Center Best Pracce Security Policy Version Version 10.1 36 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Table 1: Example Asset Categories

Most Valuable Assets Other Valuable Assets Remaining Assets (Iterate)

• Patents • Crical IT infrastructure • Network lab equipment


• Source code such as router and firewall • IT management systems
interfaces
• Confidenal data such • Other assets
as product designs, drug • Authencaon services
formulas, or user data. • Email
• Proprietary algorithms • VPNs, especially for highly
• Code signing cerficates distributed enterprises
and PKI (these are the • Crical business
keys to your encrypted applicaons
kingdom) • File sharing servers
• AD domain server (losing • Databases
the AD enables an aacker
to create credenals that
provide unlimited network
access)
• Other highly prized
assets that set your
business apart from other
businesses

Asset priority is unique to each business. For a service company, the user experience may
differenate the business from other businesses, so the most valuable assets may be assets that
ensure the best user experience. For a manufacturing company, the most valuable assets may be
proprietary processes and equipment designs. Considering the consequences of losing an asset is
a good way to figure out which assets to protect first.

Data Center Best Pracce Security Policy Version Version 10.1 37 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

How to Decrypt Data Center Traffic


You can’t protect your network against threats you can’t see and inspect. Decrypng traffic to
expose malware is crical because the majority of a typical network’s traffic is encrypted and
the amount is rising. A larger and larger percentage of malware campaigns that conceal network
intrusions, install command-and-control malware, and exfiltrate data use encrypon as well.
To expose encrypted applicaons and threats, posion physical or virtual next-generaon firewalls
so that they see all data center traffic. Decrypt all the traffic you can, especially high-risk traffic
categories, traffic desned for crical servers, and business-crical traffic. Decrypng traffic
idenfies that traffic so that the firewall can apply anvirus, vulnerability protecon, WildFire, and
other threat protecons appropriately.
To apply decrypon to traffic, create decrypon profiles that specify how to handle TLS and SSH
traffic and traffic that you choose not to or can’t decrypt. Decrypon profiles set the allowed
protocols, algorithms, modes, and session characteriscs for traffic. You apply Decrypon profiles
to Decrypon policy rules, which specify the traffic to which the firewall applies the Decrypon
profiles.
The firewall supports two types of SSL/TLS decrypon and SSH decrypon:
• SSL forward proxy (outbound traffic)
• SSL inbound inspecon (inbound traffic)
• SSH proxy (usually for secure access for administrators who manage network devices)
Within the data center, decrypt as much east-west traffic as possible. If performance
consideraons due to incorrect firewall sizing prevent you from decrypng all traffic, priorize the
most crical servers, the highest risk traffic categories, and less trusted segments and IP subnets,
and decrypt as much traffic as you can while retaining acceptable performance. Key quesons to
ask are: “What happens if this server is compromised?”, “How much risk does each category of
traffic represent?”, and “How much risk am I willing to take in relaon to the level of performance I
want to achieve inside the data center?”
For traffic flowing from the data center to the internet, decrypt everything except traffic for which
you must make excepons. The visibility that decrypon provides is especially important because
you don’t want servers in the data center to connect to malicious sites, transfer malicious files, or
be vulnerable to malware downloads.
When you plan your decrypon policy, consider your company’s security compliance rules and
posions. For traffic from users to the data center, although a ght Decrypon policy may inially
cause a few complaints, those complaints can draw your aenon to unsanconed or undesirable
websites that are blocked because they use weak algorithms or have cerficate issues. Use
complaints as a tool to beer understand the traffic on your network.
In addion, enable Decrypon logging in Decrypon policies and if resources allow, log both
successful and unsuccessful SSL handshakes. Take advantage of all of the Decrypon monitoring
and troubleshoong tools to examine your deployment and refine your policies and profiles.

Data Center Best Pracce Security Policy Version Version 10.1 38 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Decrypng traffic consumes firewall resources. The amount of traffic to decrypt varies
with each data center. When sizing the firewall deployment to maintain acceptable
performance while supporng decrypon, take into account the amount of traffic you
expect to decrypt (some applicaons must be decrypted while other applicaons aren’t
encrypted and don’t need to be decrypted), the decrypon cipher (stronger, more complex
ciphers require more processing power to decrypt), the size of the keys (larger keys
consume more decrypon resources), the type of key exchange (for example, RSA key
exchanges consume more processing resources than PFS keys), and the capacity of the
firewalls. Work with your Palo Alto Networks sales team and representaves to size the
firewall deployment appropriately for your parcular network so that you can decrypt
traffic and expose threats.

Companies with businesses such as banking that require extremely strong security for their
private keys can use a third-party hardware security module (HSM) to safeguard and manage the
company’s private key instead of storing it on the firewall.
• Create the Data Center Best Pracce Decrypon Profiles
• Exclude Unsuitable Traffic from Data Center Decrypon

Create the Data Center Best Pracce Decrypon Profiles


Decrypon profiles specify how the firewall checks decrypted traffic and also traffic that you
either can’t or choose not to decrypt. The firewall checks protocols, server cerficates, session
characteriscs, and ciphers (key exchange algorithms, encrypon algorithms, and authencaon
algorithms). You apply Decrypon profiles (Objects > Decrypon Profile) to Decrypon policy
rules (Policies > Decrypon). Decrypon policy rules define the traffic to check using the source,
desnaon, service category, and URL category as match criteria so that you have granular control
over the traffic to which you apply a Decrypon profile. You also configure decrypon logging and
log forwarding in the policy rule.
To decrypt outbound traffic, the firewall acts as a forward proxy device between the internal client
and the external server. To inspect inbound traffic, the firewall makes a copy of the incoming
session traffic and decrypts and inspects the copy.
STEP 1 | Configure the firewall to perform CRL/OCSP checks to ensure that cerficates presented
during decrypon are valid.

Data Center Best Pracce Security Policy Version Version 10.1 39 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

STEP 2 | Configure the SSL Decrypon > SSL Protocol Sengs to block vulnerable SSL/TLS versions
such as TLSv1.0, TLSv1.1, and SSLv3, and to avoid weak encrypon algorithms such as RC4
and 3DES, and weak authencaon algorithms such as MD5 and SHA1.
SSL Protocol Sengs apply to all decrypted traffic.

Set the protocol Min Version to TLSv1.2 and the Max Version to Max to block weak protocols.
Use the strongest TLS protocol that you can. Create separate Decrypon policies and profiles
to maximize security. For example, if legacy sites you need for business purposes only support
weaker protocols, create a separate Decrypon profile to allow the weaker protocol and apply
it in a Decrypon policy only to sites that don’t support at least TLSv1.2. This also applies to
necessary business sites that don’t support strong algorithms and for different URL Categories
to fine tune security vs. performance.
If the site doesn’t house a legimate business applicaon, don’t weaken your security posture
to support the site—weak protocols and ciphers contain known vulnerabilies that aackers
can exploit. If the site belongs to a category of sites that you don’t need for business purposes,
use URL Filtering to block access to the enre category. Don’t support weak protocols or weak

Data Center Best Pracce Security Policy Version Version 10.1 40 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

encrypon or authencaon algorithms unless you must do so to support important legacy


sites.
Set the Max Version to Max rather than to a parcular version so that as the protocols
improve, the firewall automacally supports the newest and best protocols. Whether you
intend to aach a Decrypon profile to a Decrypon policy rule that governs inbound (SSL
Inbound Inspecon) or outbound (SSL Forward Proxy) traffic, avoid allowing weak algorithms.

Many mobile applicaons use pinned cerficates. Because TLSv1.3 encrypts cerficate
informaon, the firewall can’t automacally add these mobile applicaons to the SSL
Decrypon Exclusion List. For these applicaons, ensure that the Decrypon profile
Max Version is set to TLSv1.2 or apply a No Decrypon policy to the traffic.

Data Center Best Pracce Security Policy Version Version 10.1 41 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

STEP 3 | Configure the SSL Decrypon > SSL Forward Proxy sengs for outbound traffic to block
excepons during TLS negoaon and block sessions that can’t be decrypted.
In some cases, the best pracce sengs depend on your company’s security compliance rules.
Apply the SSL Forward Proxy Decrypon profile to security policy rules that control outbound
traffic.

Block excepons during TLS negoaon and block sessions that can’t be decrypted.
• Server Cerficate Verificaon—Whether to check the Block sessions on cerficate status
check meout box depends on your company’s security compliance stance because
it’s a tradeoff between ghter security and a beer user experience. Cerficate status
verificaon examines the Cerficate Revocaon List (CRL) on a revocaon server or uses
Online Cerficate Status Protocol (OCSP) to find out if the issuing CA has revoked the
cerficate and the cerficate should not be trusted. However, revocaon servers can be
slow to respond, which can cause the session to meout and the firewall to block the
session even though the cerficate may be valid. If you Block sessions on cerficate status
check meout and the revocaon server is slow to respond, you can use Device > Setup

Data Center Best Pracce Security Policy Version Version 10.1 42 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

> Session > Decrypon Sengs and click Cerficate Revocaon Checking to change the
default meout value of five seconds to another value.

Enable both CRL and OCSP cerficate revocaon checking because server cerficates can
contain the CRL URL in the CRL Distribuon Point (CDP) extension or the OCSP URL in the
Authority Informaon Access (AIA) cerficate extension.
Although the best pracce is to use a proper cerficate, some cerficates leave the Subject
Alternate Name (SAN) field blank, which can cause firewalls to reject those cerficates.
Check Append cerficate’s CN value to SAN extension to automacally copy the cerficate
number to the SAN field if the SAN field is blank, so that if you do business with sites that
don’t populate the cerficate’s SAN field, you can accept their cerficates. Otherwise, the
sites need to regenerate their cerficates to conform to proper pracce and populate the
SAN field.
Block all other server cerficate verificaon excepons.
• Unsupported Mode Checks—If you don’t block sessions with unsupported versions and
unsupported cipher suites, then users receive a warning message that they can click through
to reach the risky website. The reason you configure ght SSL Protocol Sengs is to block
and protect you from servers that use these weak (risky) protocol versions and algorithms.
In addion, blocking sessions with unsupported mode checks protects you from malicious
backdoors and other threats that use custom and non-standard encrypon to obfuscate
their acvies.
Block sessions with client authencaon enables you to choose whether to allow or block
sessions that use client authencaon. Although server authencaon can be the only
authencaon used to establish a session, some sites use mutual authencaon, where
both the server and the client authencate to establish a session. Client authencaon
using an X.509 Digital Cerficate is similar to server authencaon in that both methods
use a digital cerficate issued by a trusted Cerficate Authority to authencate a session.
The client cerficate acts as a digital idenfier for the client, resides on the client device,
and can’t be ported to other devices. However, client authencaon prevents the
firewall from decrypng the session because the firewall needs both the client and server

Data Center Best Pracce Security Policy Version Version 10.1 43 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

cerficates to perform bi-direconal decrypon, but the firewall only knows the server
cerficate. This breaks decrypon for client authencaon sessions.
If you don’t enable Block sessions with client authencaon, when the firewall aempts to
decrypt a session that uses client authencaon, the firewall allows the session and adds
an entry in its local decrypt exclude cache that contains the server URL/IP address, the
applicaon, and the Decrypon profile. Entries remain in the cache for 12 hours and then
age out. If the same user or a different user aempts to access the serer within 12 hours
using client authencaon, the firewall matches the session to the decrypt exclude cache
entry, does not aempt to decrypt the traffic, and allows the encrypted session.
If the exclude cache becomes full, the firewall purges the oldest entries as new entries
arrive. If you change the Decrypon policy or profile, the firewall flushes the exclude cache
because changing the policy or profile can change the classificaon outcome of the session.
If you enable Block sessions with client authencaon, the firewall blocks sessions that
use client authencaon, with the excepon of sessions from sites on the SSL Decrypon
Exclusion list (Device > Cerficate Management > SSL Decrypon Exclusion).
You may need to allow traffic on your network from other sites that use client
authencaon in addion to the Predefined sites on the SSL Decrypon Exclusion list.
Create a Decrypon profile that allows sessions with client authencaon. Add it to a
Decrypon policy rule that applies only to the server(s) that house the applicaon. To
increase security even more, you can require Mul-Factor Authencaon to complete the
user login process.
For all other traffic, apply the Decrypon profile that blocks sessions with client
authencaon.
• Failure Checks—If you don’t Block sessions if resources not available, the risk is that a
lack of processing resources may allow potenally dangerous connecons. If you block
sessions for which resources aren’t available, it may affect the user experience. Whether to
implement failure checks depends on your company’s security compliance stance and the
importance to your business of the user experience, weighed against ghter security.
If you use a Hardware Security Module (HSM) to store your private keys, whether you check
Block sessions if HSM not available depends on your compliance rules about where the
private key must come from and how you want to handle encrypted traffic if the HSM isn’t
available. For example, if your company mandates the use of an HSM for private key signing,
then block sessions if the HSM isn’t available. However, if your company is less strict about
this, then you can consider not blocking sessions if the HSM isn’t available. (If the HSM is
down, the firewall can process decrypon for sites for which it has cached the response
from the HSM, but not for other sites.) The best pracce in this case depends on your
company’s policies. If the HSM is crical to your business, run the HSM in a high-availability
(HA) pair (PAN-OS 8.0 supports two members in an HSM HA pair).
• Block downgrade on no resource—Prevents the firewall from downgrading TLSv1.3 to
TLSv1.2 if the firewall has no available TLSv1.3 processing resources. If you block the
downgrade, then when the firewall runs out of TLSv1.3 resources, it drops traffic that uses
TLSv1.3 instead of downgrading it to TLSv1.2. If you don’t block downgrade, then when
the firewall runs out of TLSv1.3 resources, it downgrades to TLSv1.2. However, blocking
downgrade when resources aren’t available may affect the user experience by making
sites that users normally can reach temporarily unreachable. Whether to implement this
failure check depends on your company’s security compliance stance and the importance

Data Center Best Pracce Security Policy Version Version 10.1 44 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

of the user experience, weighed against ghter security. You may want to create a separate
Decrypon policy and profile to govern decrypon for sensive traffic for which you don’t
want to downgrade the TLS version.

STEP 4 | Configure the SSL Decrypon > SSL Inbound Inspecon sengs to inspect traffic from an
external client to your internal servers and block suspicious sessions.
Apply the SSL Inbound Inspecon Decrypon profile to security policy rules that control
inbound traffic.

• Unsupported Mode Checks—The firewall can’t decrypt session versions and ciphers that the
firewall doesn’t support. To prevent aackers from using unsupported versions and ciphers
to sneak onto the network, block session versions and cipher suites that the firewall doesn’t
support. In addion, blocking sessions with unsupported mode checks protects you from
malicious backdoors and other threats that use custom and non-standard encrypon to
obscure their acvies.
On the server, enable only the ciphers that you support on the firewall. Ensuring this
compability makes the negoaon between the client and the server smoother.
• Failure Checks—If you don’t Block sessions if resources not available, the risk is that a
lack of processing resources may allow potenally dangerous connecons. If you block
sessions for which resources aren’t available, it may affect the user experience. Whether to
implement failure checks depends on your company’s security compliance stance and the
importance to your business of the user experience, weighed against ghter security.
If you use a Hardware Security Module (HSM) to store your private keys, whether you check
Block sessions if HSM not available depends on your compliance rules about where the
private key must come from and how you want to handle encrypted traffic if the HSM isn’t
available. For example, if your company mandates the use of an HSM for private key signing,
then block sessions if the HSM isn’t available. However, if your company is less strict about
this, then you can consider not blocking sessions if the HSM isn’t available. (If the HSM is
down, the firewall can process decrypon for sites for which it has cached the response
from the HSM, but not for other sites.) The best pracce in this case depends on your

Data Center Best Pracce Security Policy Version Version 10.1 45 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

company’s policies. If the HSM is crical to your business, run the HSM in a high-availability
(HA) pair (PAN-OS 8.0 supports two members in an HSM HA pair).
• Block downgrade on no resource—Prevents the firewall from downgrading TLSv1.3 to
TLSv1.2 if the firewall has no available TLSv1.3 processing resources. If you block the
downgrade, then when the firewall runs out of TLSv1.3 resources, it drops traffic that uses
TLSv1.3 instead of downgrading it to TLSv1.2. If you don’t block downgrade, then when
the firewall runs out of TLSv1.3 resources, it downgrades to TLSv1.2. However, blocking
downgrade when resources aren’t available may affect the user experience by making
sites that users normally can reach temporarily unreachable. Whether to implement this
failure check depends on your company’s security compliance stance and the importance
of the user experience, weighed against ghter security. You may want to create a separate
Decrypon policy and profile to govern decrypon for sensive traffic for which you don’t
want to downgrade the TLS version.

STEP 5 | For SSH traffic, configure SSH Proxy Decrypon profile sengs.
SSH Decrypon allows normally routed SSH traffic and denies SSH tunneling (SSH port
forwarding) traffic, but doesn’t perform content or threat inspecon on the SSH traffic. SSH
tunneling sessions can tunnel X11 Windows packets and TCP packets. One SSH connecon
may contain mulple channels. When you apply an SSH Decrypon profile to traffic, for each
channel in the connecon, the firewall examines the App-ID of the traffic and idenfies the
channel type. The channel type can be:
• session
• X11
• forwarded-tcpip
• direct-tcpip
When the channel type is session, the firewall idenfies the traffic as allowed SSH traffic such
as SFTP or SCP. When the channel type is X11, forwarded-tcpip, or direct-tcpip, the firewall
idenfies the traffic as SSH tunneling traffic and blocks it.
For most user groups, you probably won’t allow SSH traffic in the data center. SSH is usually
used for remote access to servers, which is not a capability you want most users to have
because it places your data center servers at greater risk, for access to Linux servers, and for
file transfers. You can’t decrypt SSH traffic, so anyone who uses SSH to access data center

Data Center Best Pracce Security Policy Version Version 10.1 46 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

resources must be trusted—and even so, all of the threat profiles should be aached to any rule
that allows SSH access to scan for malware, viruses, spyware, etc.
An example use case for SSH is IT personnel who manage and maintain data center servers and
use SSH for remote access.

• Unsupported Mode Checks—The firewall can’t decrypt session versions and ciphers that
the firewall doesn’t support and unsupported versions and ciphers may be vulnerable. To
prevent aackers from using unsupported versions and ciphers to sneak onto the network,
block session versions and cipher suites that the firewall doesn’t support. In addion,
blocking sessions with unsupported mode checks protects you from malicious backdoors
and other threats that use custom and non-standard encrypon to obscure their acvies.
• Failure Checks—If you don’t Block sessions if resources not available, the risk is that a
lack of processing resources may allow potenally dangerous connecons. If you block
sessions for which resources aren’t available, it may affect the user experience. Whether to
implement failure checks depends on your company’s security compliance stance and the
importance to your business of the user experience, weighed against ghter security.

STEP 6 | For traffic that you choose not to decrypt, configure the No Decrypon sengs to block
encrypted sessions desned for sites with expired cerficates or untrusted issuers.
Apply the No Decrypon profile only to traffic that you choose not to decrypt because of
regulaons or compliance rules, not to traffic that can’t be decrypted because of technical

Data Center Best Pracce Security Policy Version Version 10.1 47 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

reasons, such as a pinned cerficate (add that traffic to the SSL Decrypon Exclusion List). The
best pracce is to decrypt as much data center traffic as possible.

Do not aach a No Decrypon profile to Decrypon policies for TLSv1.3 traffic that
you don’t decrypt. Unlike previous versions, TLSv1.3 encrypts cerficate informaon,
so the firewall has no visibility into cerficate data and therefore cannot block sessions
with expired cerficates or untrusted issuers, so the profile has no effect. (The firewall
can perform cerficate checks with TLSv1.2 and earlier because those protocols do not
encrypt cerficate informaon and you should apply a No Decrypon profile to their
traffic.) However, you should create a Decrypon policy for TLSv1.3 traffic that you
don’t decrypt because the firewall doesn’t log undecrypted traffic unless a Decrypon
policy controls that traffic.

Exclude Unsuitable Traffic from Data Center Decrypon


Two types of traffic are unsuitable for decrypon:
• Traffic that breaks decrypon because of technical reasons such as using client cerficate
authencaon, a pinned cerficate, or an incomplete cerficate chain.
• Traffic that you choose not to decrypt.
The firewall provides a predefined SSL Decrypon Exclusion list (Device > Cerficate
Management > SSL Decrypon Exclusion) for commonly used sites that break decrypon because
of technical reasons. You can remove predefined sites from the list by clicking the checkbox
next to the site hostname and then clicking Disable, and you can add sites to the list. Use the
Decrypon Exclusion list only for sites that break decrypon for technical reasons, don’t use it for
sites that you choose not to decrypt. If decrypon breaks an important applicaon, add it to the
Decrypon Exclusion list to create an excepon for the specific IP address, domain, or common
name in the cerficate associated with the applicaon. Some internal custom applicaons may
break if you decrypt them.
If the Decrypon profile allows Unsupported Modes (sessions with client authencaon,
unsupported versions, or unsupported cipher suites), the firewall automacally adds servers and
applicaons that use the allowed unsupported modes to the its Local Decrypon Exclusion Cache
(Device > Cerficate Management > SSL Decrypon Exclusion > Show Local Exclusion Cache).
When you block unsupported modes, you increase security but you also block communicaon
with applicaons that use those modes.

Data Center Best Pracce Security Policy Version Version 10.1 48 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

If the technical reason for excluding a site from decrypon is an incomplete cerficate
chain, you can use the informaon in the Decrypon log to repair the incomplete
cerficate chain so that you can allow, decrypt, and inspect the traffic.

You may choose not to decrypt traffic for reasons such as regulaons and legal compliance.
For example, the European Union (EU) General Data Protecon Regulaon (GDPR) will require
strong protecon of all personal data for all individuals. The GDPR affects all companies, including
foreign companies, that collect or process the personal data of EU residents. Different regulaons
and compliance rules may mean that you treat the same data differently in different countries
or regions. Businesses usually can decrypt personal informaon in their corporate data centers
because the business owns the informaon. The best pracce is to decrypt as much traffic as
possible so that you can see it and apply security protecon to it.
For traffic you choose not to decrypt, make sure it really is traffic you don’t want to decrypt,
and then create a policy-based exclusion that specifies the applicaon, user group, source and
desnaon, URL category, and/or service to limit each exclusion as much as possible. The more
specific the decrypon exclusion, the beer, so that you don’t inadvertently exclude more traffic
than necessary from decrypon.

Data Center Best Pracce Security Policy Version Version 10.1 49 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Create a Data Center Segmentaon Strategy


A flat, unsegmented network is difficult to defend because if an aacker gains access to the
network, the aacker can move laterally and compromise crical systems. This is especially true
inside the data center, where companies keep their most valuable assets. Old segmentaon
methods such as VLANs don’t scale well, are difficult to automate, and don’t take into account
users, content, or applicaons, so they provide lile control over or visibility into traffic.
Create a segmentaon strategy that provides more granular access control to data center
resources, which gives you beer visibility into traffic. The more granular your segmentaon
strategy, the more visibility into traffic you gain because traffic must traverse a firewall
(segmentaon gateway) as it flows between segments. Segmentaon also makes compliance
and compliance audits easier because you can prevent all but the necessary access to personal
informaon, which protects the data and reduces the scope of audits.
Your data center segmentaon strategy depends on your architecture and your business goals, so
there is no “one size fits all” implementaon. However, learning common guidelines enables you to
design and implement a segmentaon strategy to protect your data center network.
• How to Segment the Data Center
• How to Segment Data Center Applicaons

How to Segment the Data Center


How you segment your data center depends on your business requirements and your data
center network architecture, including your SDN soluon, which may dictate the segmentaon
method. For example, vwire interfaces control firewall connecvity on an NSX host. Because vwire
interfaces don’t route or switch traffic on an NSX host, they must belong to the same zone, so all
of the resources for a parcular tenant (department, customer, or applicaon er) reside in one
zone and the firewall uses dynamic address groups to segment applicaon traffic within that zone.
Each tenant has a separate zone with its own vwire interfaces. For other SDN soluons, separate
virtual firewall instances may segment traffic.
Next generaon Palo Alto Networks firewalls provide flexible tools to segment traffic:
• Zones —Traffic that crosses zones goes through the firewall for inspecon. All allowed data
center communicaon should traverse a firewall and undergo full threat inspecon (anvirus,
an-spyware, vulnerability protecon, file blocking, WildFire analysis, and URL Filtering for
data center traffic that leaves the enterprise and for applicaons hosted by customer tenants).
By default, the firewall denies all traffic between zones (intrazone traffic). You must write
specific security policy rules to allow traffic to pass between zones, so only traffic that you
explicitly allow can move from one zone to another. How you use zones to segment your
data center depends on what assets you need to separate from other assets. For example,
a common architecture includes separate zones for development servers and producon
servers. You can use zones to segment servers that house extremely sensive informaon
such Payment Card Informaon (PCI) or Personally Idenfiable Informaon (PII), to segment

Data Center Best Pracce Security Policy Version Version 10.1 50 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

different internal company departments such as Markeng, Engineering, and Human Resources,
and to segment customer resources and customer-hosted applicaons.
Consider using zone protecon profiles to protect zones against floods, reconnaissance
acvies (port scans and host sweeps), Layer 3 packet-based aacks, and non-IP protocol
(Layer 2) packet-based aacks.
• Dynamic address groups —For this purpose, dynamic address groups are lists of IP addresses
that the firewall imports and uses in security policy to define server groups dynamically instead
of stacally. Adding and removing IP addresses from a dynamic address group updates security
policy automacally, without a commit acon on the firewall. Within a zone, using dynamic
address groups in security policy allow rules enables server-to-server interacon for specified
applicaons and services. For example, in NSX, use dynamic address groups to segment the
server ers within an applicaon er.
• User-ID —Enable User-ID to create applicaon allow rules based on user groups to segment
users from applicaons and server groups.
When you design your data center segmentaon plan, keep in mind the following general
guidelines:
• How to Assess Your Data Center, so that you can segment it in stages and protect the most
valuable and sensive assets first.
• Use an SDN soluon (such as NSX, ACI, OpenStack) inside the data center to provide a
scalable, agile, virtualized infrastructure. SDN is the best way to centralize data center network
management, maximize compute resource ulizaon, scale and automate the network, and
control and secure traffic on a virtualized network. Although you can create a non-SDN
architecture that essenally replicates an SDN architecture, it’s difficult and me consuming to
do, prone to errors that result in outages, and is not considered a best pracce. SDN soluons
maximize the use of the underlying data center compute resources without sacrificing security.
• Use physical next-generaon firewalls to segment and secure non-virtualized legacy servers
and use VM-Series firewalls to segment and secure the virtual data center network.
• Group assets that perform similar funcons and require the same level of security in the same
data center segment. For example, place servers that connect to the internet in the same
segment.
Base your segmentaon plan on mulple criteria to develop the right plan to secure your business.

How to Segment Data Center Applicaons


Segment data center applicaons to prevent malware from moving between applicaons and to
safely enable those applicaons for users. Applicaon ers provide the resources and funcons
required for data center applicaons. An applicaon er consists of mulple server ers that
work together to fulfill requests and commands related to a parcular applicaon. Typically, an
applicaon er consists of three server ers:
• Web server er—Applicaon interface to users.
• Applicaon server er—Takes requests from the web server er to process and generate
applicaon funconality.
• Database server er—Contains data the applicaon requires to funcon.

Data Center Best Pracce Security Policy Version Version 10.1 51 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Each server er contains funconally similar servers that work together so that an applicaon er
can present an applicaon to a user.

The server ers within each applicaon er create a service chain of VMs. Service chains steer
traffic through virtual data center appliances to provide applicaon services. Within an applicaon
er, a web server may communicate with an applicaon server that houses the applicaon
code, and that applicaon server may communicate with a database server that houses content.
The communicaon between the three servers, which reside in different server ers within an
applicaon er, is the service chain.
Data centers contain many applicaon ers, which may be dedicated to parcular departments,
customers, contractors, or other groups. Segment the data center applicaon infrastructure
to prevent unauthorized and unnecessary communicaon among applicaon resources and to
inspect applicaon traffic.

Applicaon How to Segment Applicaons


Segmentaon

Applicaon er Segment the server ers within each applicaon er by configuring a
separate firewall zone for each server er, so that you can control access
to each set of servers and examine the traffic flowing between each
server er as it traverses the firewall. For example, place web servers,
applicaon servers, and database servers in separate zones so that traffic
between server ers always goes through a next-generaon firewall for full
inspecon.
Depending on business requirements, you may need to create more than one
zone for each applicaon er to separate tenants, to load balance, to use
applicaon ers for different purposes, to provide different levels of security,
or to connect to different sets of servers. Segment the data center to reduce
the aack surface of each applicaon er by grouping in the same zone only
servers that require similar levels of trust and that need to communicate with
similar applicaon ers.

Web server er Traffic normally enters the data center through web servers, although there
are special cases such as IT configuring direct secured access to data center
servers for management purposes. As with the other server ers, create a
separate zone for the web server er so that you can apply granular security
policy to it.

Data Center Best Pracce Security Policy Version Version 10.1 52 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Applicaon How to Segment Applicaons


Segmentaon
Because the web server er communicates with devices that reside outside
the data center, it’s an appealing target for aackers. Place the web server
er on a separate network, for example, using a VLAN. All traffic in and
out of the VLAN—all traffic that enters or exits the data center—should
traverse a next-generaon firewall. You can do this by configuring the next-
generaon firewall as the default gateway or by using an SDN soluon such
as NSX to steer traffic.
Segment servers within the web server er to prevent them from
communicang with each other, for example, by using a tradional rule such
as NSX Distributed Firewall (DFW) to open a port or block traffic within the
er.

Infrastructure Segment the servers that provide crical infrastructure services such as DNS,
service DHCP, and NTP, and allow access only to their specific IP addresses, using
applicaon only the appropriate applicaons.
servers

Applicaons Use App-ID to create applicaon-based allow list security policy rules that
segment applicaons by controlling who can access each applicaon and on
which sets of servers (using dynamic address groups). App-ID enables you
to apply granular security policy rules to applicaons that may reside on the
same compute resource but require different levels of security and access
control.
Create custom applicaons to uniquely idenfy proprietary applicaons and
segment access. If you have exisng Applicaon Override policies that you
created solely to define custom session meouts for a set a of ports, convert
the exisng Applicaon Override policies to applicaon-based policies by
configuring service-based session meouts to maintain the custom meout
for each applicaon and then migrang the rule the an applicaon-based
rule. Applicaon Override policies are port-based. When you use Applicaon
Override policies to maintain custom session meouts for a set of ports, you
lose applicaon visibility into those flows, so you neither know nor control
which applicaons use the ports. Service-based session meouts achieve
custom meouts while also maintaining applicaon visibility.
For migrang from a port-based security policy with custom applicaon
meouts to an applicaon-based policy, don’t use Applicaon Override
rules to maintain the custom meouts because you lose visibility into the
applicaons. Instead, define a service-based session meout to maintain
the custom meout for each applicaon, and then migrate the rule to an
applicaon-based rule.

Don’t use next-generaon firewalls to segment servers within a parcular server er. When you
need to prevent intercommunicaon of servers within a server er, use a tradional rule such
as NSX DFW to open a port or block traffic within the er. However, servers within a server er

Data Center Best Pracce Security Policy Version Version 10.1 53 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

oen need to intercommunicate. For example, a database server er may be a server cluster that
requires free intercommunicaon.

Data Center Best Pracce Security Policy Version Version 10.1 54 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

How to Create Data Center Best Pracce Security


Profiles
Security profiles provide fundamental protecons by scanning traffic that you allow on the
network for threats. Security profiles provide a full suite of coordinated threat prevenon tools
that block peer-to-peer command and control (C2) applicaon traffic, dangerous file types,
aempts to exploit vulnerabilies, and anvirus signatures, and also idenfy new and unknown
malware.
It takes relavely lile effort to apply security profiles because Palo Alto Networks provides
predefined profiles that you can simply add to security policy allow rules. Customizing security
profiles is easy because you can clone a predefined profile and then edit it. Of course, you can also
create a security profile from scratch on the firewall or on Panorama.
To detect known and unknown threats in your network traffic, aach security profiles to all
security policy rules that allow traffic on the network, so that the firewall inspects all allowed
traffic. The firewall applies security profiles to traffic that matches the security policy allow rule,
scans traffic in accordance with the security profile sengs, and then takes appropriate acons to
protect the network. The recommendaons for best pracce security profiles apply to all four of
the data center traffic flows except as noted.

Download content updates automacally and install them as soon as possible so that
you have the latest threat prevenon signatures and content (anvirus, an-spyware,
vulnerabilies, malware, etc.) on the firewall and block the latest threats.

• Create the Data Center Best Pracce Anvirus Profile


• Create the Data Center Best Pracce An-Spyware Profile
• Create the Data Center Best Pracce Vulnerability Protecon Profile
• Create the Data Center Best Pracce File Blocking Profile
• Create the Data Center Best Pracce WildFire Analysis Profile

Create one or more Security profile groups so that you can apply all of the profiles to a
Security policy rule at one me instead of specifying them individually.

You don’t need a URL Filtering subscripon for data center firewalls if there is no direct outbound
connecon to the internet. Firewalls that don’t connect directly to the internet don’t need the
PAN-DB URL Filtering soluon because it idenfies internet URLs, not private data center URLs,
so imporng the PAN-DB database and checking URLs against it doesn’t apply to data center
traffic. If you’re not sure whether a firewall has URL traffic, get a trial URL Filtering subscripon
and set the profile to alert on all URL categories to idenfy any URL traffic. Otherwise, URL
Filtering should take place on firewalls at the network perimeter where user traffic enters and
exits the network, not at the data center perimeter. Consider creang custom URL categories
(Objects > Custom Objects > URL Category) to idenfy and control access to internal data center
web services.

Data Center Best Pracce Security Policy Version Version 10.1 55 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Create the Data Center Best Pracce Anvirus Profile


Clone the default Anvirus profile and edit it. To ensure availability for business-crical
applicaons, take safe transion steps as you move from your current state to the best pracce
profile. To achieve the best pracce profile, modify the default profile as shown here and aach it
to all security policy rules that allow traffic. The Anvirus profile has protocol decoders that detect
and prevent viruses and malware from being transferred over seven protocols: FTP, HTTP, HTTP2,
IMAP, POP3, SMB, and SMTP. You can set WildFire acons for all seven protocols because the
Anvirus profile also enforces acons based on WildFire signatures and in-line machine learning.
Configure the cloned best pracce Anvirus profile to reset both the client and the server for all
seven protocol decoders and WildFire acons, and then aach the profile to the allow rules for all
four data center traffic flows.

Red triangles in the upper le corner of a cell indicates that the acon is modified (changed from
the default) and the name of the modified profile is Strict_AV.
Aach the best pracce Anvirus profile to all security policy rules that allow traffic to block
known malicious files (malware, ransomware bots, and viruses) as they aempt to enter the
network. For example:
• Intra data center traffic—The Anvirus profile, along with the Vulnerability Protecon profile,
helps prevent aackers from using exploits to leverage vulnerabilies and spread malware and
hacking tools laterally between servers inside the data center network.
• Traffic from the data center to the internet—The Anvirus profile, along with the An-Spyware
profile, helps idenfy and block command and control traffic and inial downloads of malware
and hacking tools.

Create the Data Center Best Pracce An-Spyware Profile


Aach an An-Spyware profile to all security policy rules that allow data center traffic. The An-
Spyware profile detects command-and-control (C2) traffic iniated from spyware installed on a
server or endpoint, including categories such as adware, backdoor, browser-hijack, data the, and
keylogging, and prevents compromised systems from establishing an outbound connecon from
your network.

Data Center Best Pracce Security Policy Version Version 10.1 56 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Clone the predefined strict An-Spyware profile and edit it. To ensure availability for business-
crical applicaons, take safe transion steps as you move from your current state to the best
pracce profile. If you have a sinkhole set up to which you can send traffic for analysis, enable
DNS sinkhole with packet capture to help you track down the endpoint that aempted to resolve
the malicious domain. The best pracce An-Spyware profile retains the default Acon to reset
the connecon when the firewall detects a medium, high, or crical severity threat, and enables
single packet capture (PCAP) for those threats.

Don’t enable PCAP for informaonal acvity because it generates a relavely high volume of that
traffic and it’s not parcularly useful compared to potenal threats. Apply extended PCAP (as
opposed to single PCAP) to high-value traffic to which you apply the alert Acon. Apply PCAP
using the same logic you use to decide what traffic to log—take PCAPs of the traffic you log. Apply
single PCAP to traffic you block. The default number of packets that extended PCAP records and
sends to the management plane is five packets, which is the recommended value. In most cases,
capturing five packets provides enough informaon to analyze the threat. If too much PCAP traffic
is sent to the management plane, then capturing more than five packets may result in dropping
PCAPs.
The best pracce Acon on DNS Queries is to block or to sinkhole DNS queries for known
malicious domains and when you don’t have visibility into DNS queries, and to enable PCAPs.

Enabling DNS sinkhole idenfies potenally compromised hosts that aempt to access suspicious
domains by tracking the hosts and prevenng them from accessing those domains. Enable DNS

Data Center Best Pracce Security Policy Version Version 10.1 57 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

sinkhole when the firewall can’t see the originator of the DNS query (typically when the firewall is
north of the local DNS server) so that you can idenfy infected hosts. Don’t enable DNS sinkhole
when the firewall can see the originator of the DNS query (typically when the firewall is south of
the local DNS server; in this case, the firewall’s blocking rules and logs provide visibility into the
traffic) or on traffic you block.
In addion to protecng hosts with DNS sinkholing, aach the best pracce An-Spyware profile
to all security policy rules that allow traffic to idenfy infected hosts as traffic leaves the network
and to stop aackers by prevenng compromised systems from communicang with the malicious
C2 network. If a system can’t communicate with the C2 network, the C2 network can’t control the
system. For example:
• Traffic from users to the data center, intra data center traffic, and traffic from the internet to
the data center—The An-Spyware profile blocks peer-to-peer C2 traffic.
• Traffic from the data center to the internet—The An-Spyware profile, along with the Anvirus
profile, helps idenfy and block C2 traffic and inial downloads of malware and hacking tools.

Create the Data Center Best Pracce Vulnerability Protecon


Profile
Aach a Vulnerability Protecon profile to all security policy rules that allow traffic. The
Vulnerability Protecon profile protects against buffer overflows, illegal code execuon, and other
aempts to exploit client- and server-side vulnerabilies to breach and move laterally through the
data center network.
Clone the predefined strict Vulnerability Protecon profile. To ensure availability for business-
crical applicaons, take safe transion steps as you move from your current state to the best
pracce profile. For the best pracce profile, for each rule except simple-client-informaonal
and simple-server-informaonal, double-click the Rule Name and change Packet Capture from
disable to single-packet to enable packet capture (PCAP) for each rule so you can track down
the source of potenal aacks. Don’t change the rest of the sengs. Download content updates
automacally and install them as soon as possible so that the signature set is always up-to-date.

Data Center Best Pracce Security Policy Version Version 10.1 58 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Don’t enable PCAP for informaonal acvity because it generates a relavely high volume of that
traffic and it’s not parcularly useful compared to potenal threats. Apply extended PCAP (as
opposed to single PCAP) to high-value traffic to which you apply the alert Acon. Apply PCAP
using the same logic you use to decide what traffic to log—take PCAPs of the traffic you log. Apply
single PCAP to traffic you block. The default number of packets that extended PCAP records and
sends to the management plane is five packets, which is the recommended value. In most cases,
capturing five packets provides enough informaon to analyze the threat. If too much PCAP traffic
is sent to the management plane, then capturing more than five packets may result in dropping
PCAPs.
The reason to aach the best pracce Vulnerability Protecon profile to all security policy rules
that allow traffic is because if you don’t have strict vulnerability protecon, aackers can leverage
client- and server-side vulnerabilies to compromise the data center. For example:
• Intra data center traffic—A strict Vulnerability Protecon profile, along with the Anvirus
profile, helps prevent aackers from using exploits to leverage vulnerabilies and spread
malware and hacking tools laterally between servers inside the data center network.
• Traffic from the data center to the internet—Vulnerability protecon helps prevent infected
data center servers from compromising internet servers.
• Traffic from the internet to the data center—A strict Vulnerability Protecon profile blocks
aempts to compromise data center servers with server-side vulnerabilies. If a server is
compromised, vulnerability protecon helps prevent the infected server from serving exploits
to clients, isolang the infecon and protecng your partners and customers from watering
hole aacks. Vulnerability protecon also stops brute force aacks using the Block IP acon.
When brute force aack signatures trigger the acon, the firewall blocks the aacker’s IP
address for a configured period of me. If the brute force aack resumes aer the me period
expires, the signatures again trigger the blocking acon. The brute force aack may connue,
but it never succeeds.

Data Center Best Pracce Security Policy Version Version 10.1 59 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Create the Data Center Best Pracce File Blocking Profile


Use the predefined strict File Blocking profile to block files that are commonly included in
malware aack campaigns and that have no real use case for upload/download. Blocking
these files reduces the aack surface. The predefined strict profile blocks batch files,
DLLs, Java class files, help files, Windows shortcuts (.lnk), BitTorrent files, .rar files, .tar
files, encrypted-rar and encrypted-zip files, mul-level encoded files (files encoded or
compressed up to four mes), .hta files, and Windows Portable Executable (PE) files, which
include .exe, .cpl, .dll, .ocx, .sys, .scr, .drv, .efi, .fon, and .pif files. The predefined strict profile alerts
on all other file types for visibility into other file transfers so that you can determine if you need to
make policy changes.

In some cases, the need to support crical applicaons may prevent you from blocking
all of the strict profile’s file types. Follow the safe transion advice to help determine
whether you need to make excepons in different areas of the network. Review the data
filtering logs (Monitor > Logs > Data Filtering) to idenfy file types used in the data center
and talk with business stakeholders about the file types their applicaons require. Based
on this informaon, if necessary, clone the strict profile and modify it as needed to allow
only the other file type(s) that you need to support the crical applicaons. You can also
use the Direcon seng to restrict files types from flowing in both direcons or block files
in one direcon but not in the other direcon.

The reason to aach the best pracce File Blocking profile to all security policy rules that allow
traffic is to help prevent aackers from delivering malicious files to the data center through file
sharing applicaons and exploit kits, or by infecng users who access the data center, or on USB
scks.
• Traffic from users to the data center—Aach the strict File Blocking profile to security policy
rules for applicaons that don’t entail file sharing or collaboraon to block dangerous file types
that can deliver exploits and malware.
• Intra data center traffic—Aach the strict File Blocking profile to security policy rules to prevent
a compromised server from sharing a malicious file with other servers in the data center. This
isolates the infecon and prevents the spread of malware through the data center.
• Traffic from the data center to the internet—Limit file transfers to the file types required by the
applicaon in use.
If you don’t block all Windows PE files, send all unknown files to WildFire for analysis. For user
accounts, set the Acon to connue to help prevent drive-by downloads where malicious web
sites, emails, or pop-ups cause users to inadvertently download malicious files. Educate users that

Data Center Best Pracce Security Policy Version Version 10.1 60 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

a connue prompt for a file transfer they didn’t knowingly iniate may mean they are subject to a
malicious download.

Create the Data Center Best Pracce WildFire Analysis Profile


The other security profiles detect and block known threats. WildFire protects the data center
from unknown threats. Configure the firewall to forward all unknown files to WildFire for analysis
using the predefined default profile. Unknown threats can hide in many different file types and
successful aacks may not be detected unl long aer they have done damage. For example,
WildFire can idenfy malware loaded onto a staging server before the aacker can do damage and
find vulnerability scanners and lateral movement assistance tools before aackers achieve their
goals. WildFire could have prevented a number of large-scale enterprise breaches over the past
several years. Any security policy rule that controls traffic that has, will have, or could have file
transfer acvity should include an enabled WildFire Analysis profile.

Set up WildFire appliance content updates to download and install automacally every
minute so that you always have the most recent support. For example, support for Linux
files and SMB files were first delivered in WildFire appliance content updates.

The reason to aach the default WildFire Analysis profile to all security policy rules that allow
traffic is because WildFire provides the best defense against unknown threats and advanced
persistent threats (APTs). For example:
• Traffic from users to the data center—WildFire idenfies unknown malware hosted in the data
center such as Confluence or SharePoint.
• Intra data center traffic—WildFire idenfies unknown malware spreading among the data
center servers, which can prevent the exfiltraon of data by discovering the malware before it
can do damage.

Data Center Best Pracce Security Policy Version Version 10.1 61 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

• Traffic from the data center to the internet—Because this traffic downloads executables for
soware and operang system updates, it’s crical to run WildFire on all applicaons to
idenfy malicious behaviors.
Set up alerts for malware through email, SNMP, or a syslog server so that the firewall immediately
nofies you when it encounters a potenal issue. The faster you isolate a compromised host, the
lower the chance that the previously unknown malware has spread to other data center devices,
and the easier it is to remediate the issue.
If necessary, you can restrict the applicaons and file types sent for analysis based on the traffic’s
direcon.

WildFire Acon sengs in the Anvirus profile may impact traffic if the traffic generates
a WildFire signature that results in a reset or a drop acon. You can exclude internal
traffic such as soware distribuon applicaons through which you deploy custom-built
programs to transion safely to best pracces, because WildFire may idenfy custom-
built programs as malicious and generate a signature for them. Check Monitor > Logs
> WildFire Submissions to see if any internal custom-built programs trigger WildFire
signatures.

Data Center Best Pracce Security Policy Version Version 10.1 62 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Use Cortex XDR Agent to Protect Data Center


Endpoints
Cortex XDR Agent protects data center endpoints such as servers and VMs against malware and
exploits on the endpoint itself, while the next-generaon firewall protects against threats that
cross the network (and therefore must traverse the firewall) to reach the endpoint. When malware
or exploits are already on an endpoint or get onto an endpoint, if the endpoint executes the threat
(for example, through an .exe or .dll file), the firewall doesn’t see the threat because the acon
is on the endpoint and no traffic crosses the firewall, so there’s nothing for the firewall to see.
However, on each endpoint, Cortex XDR Agent sees threats in executables, macros in documents,
dynamic-link library files, and more. When these threats aempt to run, Traps goes into acon on
the endpoint itself and protects the endpoint.
Cortex XDR Agent and the next-generaon firewall provide a double layer of protecon to data
center endpoints so that the firewall protects endpoints from threats on the network while Cortex
XDR Agent monitors and protects endpoints against threats that reside on the endpoint. The
security policy you configure for endpoints on an Endpoint Security Manager (ESM) and the
security policy you configure on Panorama or on the firewall don’t conflict because they govern
different events at different locaons. Cortex XDR Agent controls security within each individual
endpoint. The firewall controls security of traffic that traverses the firewall.
Install Cortex XDR Agent on every data center endpoint. The best pracces for Cortex XDR Agent
in the data center are the same as the best pracces for Cortex XDR Agent on any endpoint
because the context is always the endpoint itself, so the context “in the data center” or “in a
user group” doesn’t maer—Cortex XDR Agent protects all endpoints the same way. So the
deployment process, the malware protecon policy best pracces, etc., are the same for the data
center as for any other area of the network.

Data Center Best Pracce Security Policy Version Version 10.1 63 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Create Data Center Traffic Block Rules


Before you create the applicaon allow rules for the four data center traffic flows, create
blocking and logging rules to block applicaons you don’t use in the data center, block known
bad applicaons, and discover applicaons that you may not know are on your network. Logging
blocked traffic provides informaon about potenal aacks to help you invesgate them.
When you discover unknown applicaons, decide whether they should be allowed or whether
they represent potenal threats. If these rules discover applicaons that should be allowed, tune
the applicaon allow rules accordingly. If these rules discover applicaons that are not legimate,
they may represent potenal threats and you can invesgate them using the log informaon.
Don’t apply Security Profiles to block rules because the traffic they control never gets into your
network.

If you discover unknown applicaons that are internal proprietary applicaons or


other types of legimate applicaons, create a custom applicaon for each unknown
applicaon so that you can idenfy it and apply security policy to it.

Order the Data Center Security Policy Rulebase shows you how to order these rules with all of the
other rules we create for the four data center traffic flows so that no rule shadows another rule.

To apply consistent security policy across mulple data centers, you can reuse templates
and template stacks so that the same policies apply to every data center. The templates
use variables to apply device-specific values such as IP addresses, FQDNs, etc., while
maintaining a global security policy and reducing the number of templates and template
stacks you need to manage.

STEP 1 | Block Quick UDP Internet Connecons (QUIC) protocol.


Chrome and some other browsers establish sessions using QUIC instead of TLS, but QUIC
uses proprietary encrypon that the firewall can’t decrypt, so potenally dangerous traffic may

Data Center Best Pracce Security Policy Version Version 10.1 64 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

enter the network as encrypted traffic. Blocking QUIC forces the browser to fall back to TLS
and enables the firewall to decrypt the traffic.
Create a Security policy rule to block QUIC on its UDP service ports (80 and 443) and create
a separate rule to block the QUIC applicaon. For the rule that blocks UDP ports 80 and 443,
create a Service (Objects > Services) that includes UDP ports 80 and 443:

Use the Service to specify the UDP ports to block for QUIC. In the second rule, block the QUIC
applicaon so that the first two rules in your rulebase block QUIC:

STEP 2 | Block all applicaons from user zones on the applicaon-default port to idenfy unexpected
applicaons.
This rule discovers applicaons that users are aempng to use and that you didn’t know
were running on your data center. Monitor traffic that matches this rule to determine if it’s a
potenal threat or if you need to modify your allow rules to enable access to the applicaon.

Data Center Best Pracce Security Policy Version Version 10.1 65 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Be sure to place this rule aer rules that allow traffic or this rule will block traffic that you
intend to allow.

The rule shown aer this rule is similar to this rule, except that it applies to traffic from
any source, not just traffic from user zones. The reason for creang separate rules is
that violaons of the user-zone rule may indicate that you’re blocking a legimate
applicaon which some users need to conduct business, so you may need to modify
a rule to allow the applicaon for a parcular set of users. Violaons from non-
user zones may indicate a change in an applicaon or a potenal aack. Creang a
separate rule for the rest of the traffic enables you to view separate logs for user traffic
and for all other traffic aempng to enter the data center, which makes it easier to
invesgate and respond to a potenal issue.
This rule must precede the next rule, which applies to all traffic so that you can log
and monitor aempts to use unexpected applicaons on applicaon-default ports
regardless of the source aer you first log violaons from user zones.

To create this rule:


• The Source Zone includes all user zones and users (your deployment may have more user
zones than shown in the example).
• The Desnaon Zone is the data center web server er (Web-Server-Tier-DC) at the data
center perimeter.
• Set the Applicaon to any and the Service to applicaon-default so that the rule applies to
all applicaons running on their standard ports.
• Set the Acon to Drop to silently drop the traffic without sending a signal to the client or
server.

STEP 3 | Block all applicaons from user zones on any port to idenfy applicaons running where they
shouldn’t run.
This rule idenfies legimate, known applicaons that users are aempng to run on non-
standard ports as well as unknown applicaons for which you may need to create custom
applicaons. Invesgate the source of any traffic that matches this rule to ensure that you

Data Center Best Pracce Security Policy Version Version 10.1 66 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

aren’t allowing unknown-tcp, unknown-udp, or non-syn-tcp traffic. Be sure to place this rule
aer rules that allow traffic or this rule will block traffic that you intend to allow.

We will also create a different block rule later in this secon that is similar to this rule
(Unexpected-App-from-Any-Zone), except that it applies to traffic from any source,
not just traffic from user zones. The reason for creang separate rules is that violaons
of the user-zone rule may indicate that a legimate applicaon which some users need
to conduct business has not been designed correctly, so you may need to modify the
applicaon. Creang a separate rule for the rest of the traffic enables you to view
separate logs for user traffic and for all other traffic aempng to enter the data
center, which makes it easier to invesgate and respond to a potenal issue.

To create this rule:


• The Source Zone includes all user zones and users (your deployment may have more user
zones than shown in the example).
• The Desnaon Zone is the data center web server er (Web-Server-Tier-DC) at the data
center perimeter.
• Set the Applicaon to any and the Service to any so that the rule applies to all applicaons
running on any port.
• Set the Acon to Drop to silently drop the traffic without sending a signal to the client or
server.

STEP 4 | Block applicaons designed to evade or bypass security, that aackers commonly exploit, or
that are not necessary in the data center.
This rule protects the data center from applicaons that you know you don’t want on your
network. Although the goal of a best pracce security policy is posive enforcement using
applicaon allow rules, explicitly blocking and logging potenally dangerous applicaon acvity
such as unsanconed file sharing applicaons, remote access applicaons, or encrypted
tunnels, provides visibility into and informaon about potenal aacks. Even aer you develop

Data Center Best Pracce Security Policy Version Version 10.1 67 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

a solid applicaon allow list, keep this applicaon blocking rule in the rulebase because logs
from aempted violaons help with invesgaons into potenal aacks.

Use this rule to block only applicaons you never want in your data center.

To create this rule:


• Set the Source Zone, Address, User, and Device to any because you’re blocking applicaons
that nobody should be allowed to use in the data center.
• Specify all data center zones in the Desnaon Zone to protect all data center servers from
bad applicaons.
• Create an applicaon filter for each type (category) of applicaon you want to block and
specify any addional applicaons. This example includes applicaon filters for encrypted
tunnels, remote access, and file sharing. Block applicaons that you don’t use in the data
center to reduce the aack surface by eliminang unnecessary applicaons, which also
reduces risk. The advantage of using applicaon filters instead of applicaon groups or
lisng individual applicaons is that filters are automacally updated, so you don’t need to
maintain them as new applicaons come out.
• Set the Service to any to catch undesired applicaons on non-standard ports as well as
default ports.
• Set the Acon to Drop to silently drop the traffic without sending a signal to the client or
server.
The applicaon filters shown in the example rule are not a comprehensive list. Evaluate the
applicaon list you create based on How to Assess Your Data Center and add the applicaons
you don’t want to allow to this rule. Place this blocking rule aer the allow rules to allow
excepons to the rule. For example, IT needs to use remote access applicaons to manage
data center devices, so you must allow that use of remote access applicaons before you block
remote access applicaons for all other users. Another example is that you may sancon one
or two file sharing applicaons in allow rules that precede this block rule, and the applicaon
filter in this rule then blocks all the rest of those applicaons. If there are sets of applicaons
or individual applicaons that you never want on your network and for which there are no
excepons, you can create a specific block rule to block just those applicaons and place it at
the top of the rulebase, above the applicaon allow rules. However, if you do this, you must be
certain that none of the blocked applicaons have legimate business uses because your users
will not be able to access them.

STEP 5 | Block all applicaons from any zone on the applicaon-default port to idenfy unexpected
applicaons.
This rule discovers applicaons from any zone that you didn’t know were running on your data
center. Violaons of this rule may indicate that an applicaon has changed or may indicate a

Data Center Best Pracce Security Policy Version Version 10.1 68 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

potenal threat. Monitor traffic that matches this rule to determine if it’s a potenal threat or if
you need to modify your applicaon allow rules. Be sure to place this rule aer rules that allow
traffic or this rule will block traffic that you intend to allow, and aer the rule in Step 1 so that
it doesn’t catch traffic from user zones.

To create this rule:


• The Source is any to cover all of the rest of the traffic aempng to enter the data center
(the rule in Step 1 blocks and idenfies unexpected user applicaons before traffic hits this
rule).
• The Desnaon Zone is the data center web server er (Web-Server-Tier-DC) at the data
center perimeter.
• Set the Applicaon to any and the Service to applicaon-default so that the rule applies to
all applicaons running on their standard ports.
• Set the Acon to Drop to silently drop the traffic without sending a signal to the client or
server.

STEP 6 | Block all applicaons from any zone on any port to idenfy applicaons running where they
shouldn’t run.
This rule idenfies legimate, known applicaons aempng to run on non-standard ports
as well as unknown applicaons for which you may need to create custom applicaons.
Invesgate the source of any traffic that matches this rule to ensure that you aren’t allowing
unknown-tcp, unknown-udp, or non-syn-tcp traffic. Be sure to place this rule aer rules that
allow traffic or this rule will block traffic that you intend to allow, and aer the preceding rule
so that it doesn’t catch traffic from user zones.

To create this rule, use the same sengs as in the rule Unexpected-App-from-User-Zone,
except instead of specifying the user zones in the source, specify any zone to cover all of the
rest of the traffic aempng to enter the data center, and set the Service to any to cover non-
standard ports.

STEP 7 | Discover unknown users aempng to run any applicaon, on any port.
This rule idenfies gaps in User-ID coverage by finding unknown users. It also idenfies
compromised or embedded devices in the user community that are trying to access your data
center. (Embedded devices have no user interface, for example, printers, card readers, and
cameras, but adversaries can compromise these devices and use them in an aack.)

This rule is almost the same as the interzone-default rule that prevents communicaon
between zones (unless another rule allows the traffic), except instead of dropping traffic
from all users, it only drops traffic from unknown users. This enables you to log rule matches
separately and more easily invesgate unknown users aempng to access your data center.

Data Center Best Pracce Security Policy Version Version 10.1 69 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Define the Inial User-to-Data-Center Traffic Security


Policy
Defining the inial best pracce security policy for user traffic flowing to the data center begins
the process of developing a data center applicaon allow list. The ulmate goal is to use posive
security enforcement to protect your data center with a Zero Trust architecture by explicitly
controlling who can access the data center, which data center applicaons they can access,
and what resources they can access inside the data center. When you finish developing your
best pracce security policy, no unknown users should be able to access the data center and no
unknown applicaons or resources should reside in the data center.
• User-to-Data-Center Traffic Security Approaches
• Create User-to-Data-Center Applicaon Allow Rules
• Create User-to-Data-Center Authencaon Policy Rules
• Create User-to-Data-Center Decrypon Policy Rules

User-to-Data-Center Traffic Security Approaches


The tradional legacy approach to securing user traffic flowing to the data center leaves valuable
assets exposed to risk, while the best pracce approach protects your valuable assets.

The Tradional Risk The Best Pracce Approach


Approach

Port-based rules Malicious applicaons access Applicaon allow rules e together


provide sufficient the network by spoofing applicaons, users, and servers so that
security because port numbers, tunneling only legimate users using sanconed
the data center is through a port, or using port applicaons can access the right sets of
inside a trusted hopping to avoid detecon. data center servers.
network.
When you transion from
port-based to applicaon-
based rules, in the rulebase,
place the applicaon-based
rule above the port-based
rule it will replace. Reset the
policy rule hit counter for
both rules. If traffic hits the
port-based rule, its policy rule
hit count increases. Tune the
applicaon-based rule unl
no traffic hits the port-based
rule for a period of me, then
remove the port-based rule.

Data Center Best Pracce Security Policy Version Version 10.1 70 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

The Tradional Risk The Best Pracce Approach


Approach

Trust internal An aacker gains access to Enable User-ID, block unknown users, and
users and allow a data center endpoint and allow access for sanconed users. Create
the applicaon then moves laterally to any separate identy domains for employees,
the user accesses other data center endpoint partners, and contractors. Use mul-
to determine to exploit stolen credenals factor authencaon (MFA) for partner,
whether access or server-side vulnerabilies. contractor, and sensive server access.
is allowed based Unknown users gain access
on credenals to data center endpoints.
and possibly on IP
address rules.

Analyzing Users may inadvertently Send all unknown files to WildFire for
unknown files download malware from analysis to idenfy new and unknown
is unnecessary file sharing and other cloud malware and protect against it.
because the data applicaons.
center is inside a
trusted network.

A mix of threat A conglomeraon of The Palo Alto Networks suite of


prevenon individual tools leaves coordinated security tools works together
profiles from security holes for aackers to plug security holes and prevent aacks.
mulple vendors. and may not work together
well.

Create User-to-Data-Center Applicaon Allow Rules


When you assess your data center, you gain the informaon to cra a set of applicaon allow
rules based on purposeful decisions about who should have access to which applicaons running
on which sets of servers. Cra the applicaon security policy allow rules (Policies > Security) so
that only the users you explicitly allow can use only the applicaons that pertain to their work on
only the right sets of servers. Allow no unnecessary access, no unknown users, and no unknown
applicaons.

Tag all sanconed applicaons with the predefined Sanconed tag. Panorama and
firewalls consider applicaons without the Sanconed tag as unsanconed applicaons.

Order the Data Center Security Policy Rulebase shows you how to order these rules with all of the
other rules we create for the other three data center traffic flows and the block rules so that no
rule shadows another rule.

To apply consistent security policy across mulple data centers, you can reuse templates
and template stacks so that the same policies apply to every data center. The templates
use variables to apply device-specific values such as IP addresses, FQDNs, etc., while
maintaining a global security policy and reducing the number of templates and template
stacks you need to manage.

Data Center Best Pracce Security Policy Version Version 10.1 71 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Each of the following allow rules:


• Has the best pracce Security profile group aached, which consists of the best pracce
Security profiles. Using a Security profile group enables you to apply all of the best pracce
profiles to a rule at one me instead of specifying each profile individually. Security profile
groups make configuring protecon against malware, vulnerabilies, C2 traffic, and known and
unknown threats faster and easier.
• Logs traffic (at session end) so that you can track and analyze rule violaons and includes log
forwarding. Forward logs to log servers and when applicable, forward log emails to appropriate
administrators.
STEP 1 | Enable the appropriate user access to your internal corporate DNS servers (don’t enable
access to external DNS servers).
This rule restricts access to your corporate DNS servers, which reduces the aack surface and
helps protect DNS entries about internal hosts and services. To avoid discovery by public DNS
queries, DNS entries for internal corporate resources aren’t stored in publicly available DNS
servers, so the only way an aacker can learn those entries is to compromise the corporate
DNS server, so your DNS servers are aracve targets.

At the internet gateway (network perimeter), block all DNS traffic to public DNS
servers. Do not allow DNS traffic to go out to the internet.

This rule is an excepon to the best pracce of not allowing “any” user in policy rules because
users need to access DNS services before they log in. This rule safeguards access to DNS
services. To create this rule:
• Restrict access to the appropriate Desnaon Zone in the data center, IT infrastructure.
• Configure an address group for the DNS Servers and restrict access to only that group.
• Prevent access using any applicaon except dns.
• It’s especially import to apply the best pracce Security profile group to DNS traffic because
if an aacker hijacks your DNS server, the aacker can redirect traffic to phishing websites
that look like the legimate websites users are trying to access.

STEP 2 | Allow the necessary IT personnel secured, privileged access to data center servers for
management and maintenance.
This rule shows how to safeguard access to crical systems for users who have privileged
accounts. Privileged accounts require a high level of trust and grant administrave access to
crical systems that contain your company’s most valuable data, so you must ghtly control
and monitor privileged accounts. Leverage App-ID to specify only the applicaons IT users

Data Center Best Pracce Security Policy Version Version 10.1 72 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

need to manage data center devices so that the firewall denies access for all other applicaons.
In this example, a group of IT users needs administrave access to manage data center servers.

IT privileged access for data center server management should be limited to


management interfaces only, and should be on a dedicated VLAN so that server
management traffic is separate from other traffic. The management interfaces should
be on the same subnet. Don’t allow this type of access on data interfaces. If the IT
group uses SSH or RDP for management access, don’t allow SSH or RDP access for
other purposes.
Your IT networking team’s organizaon determines whom to allow IT privileged access.
For each type of privileged access, group servers and other devices by their access
requirements. Allow only the necessary IT users to access each set of servers, using only
applicaons required for device management.

To create this rule:


• Because only a subset of IT users may manage data center servers, leverage User-ID to
create a group specifically for IT users who require that level of privileged access (in this
example it-superusers).
• Create a stac address group (IT-Server-Management) that contains the management
interface addresses of the servers you want the it-superusers to manage and restrict the
Desnaon to that address group in the IT-server-access-DC zone.
• Allow only the applicaons the IT superusers need to perform their business dues, on the
default ports. In this example, the rule allows the ssl, ssh, and ms-rdp applicaons.

The allowed applicaons are examples. Allow the applicaons your IT department
uses to manage data center servers. In some cases, applicaons over SSL may
require the addion of the specific applicaon to be idenfied correctly by App-ID.
IT personnel also manage switches, routers, and other devices in the data center. If the
same group of IT users manages those resources using the same applicaons, you can add
them to the desnaon zone and address so that the rule allows IT superusers to access the
management interfaces of those devices. If different IT user groups manage different sets of
data center resources or use different applicaons, create separate, ght security policy rules
for each user group and each set of applicaons.
Because user groups that have privileged accounts have access to crical systems, when
you Create User-to-Data-Center Authencaon Policy Rules, require MFA to prevent access
if aackers compromise their credenals. Create corresponding authencaon policy and
decrypon policy rules for each privileged access rule.

STEP 3 | Allow access for employee user groups that have legimate business reasons to
communicate with data center servers.
This rule shows how to limit each user group’s (or in some cases, an individual user’s) access
to only the necessary applicaons and servers. For example, engineers need to access
development servers in the data center. To create the security policy rule, create a dynamic

Data Center Best Pracce Security Policy Version Version 10.1 73 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

address group that contains the IP addresses of all of the data center development servers
that the group uses, idenfy the applicaons the engineers need to use on those servers, and
construct the rule based on those groups.

To create this rule:


• Specify the engineering user groups that need access to engineering servers in the data
center, in this example, api-users and engg-users.
• Restrict access to the data center development servers by creang a dynamic address group
(Dev-Servers) for them and seng it as the Desnaon Address.
• Restrict access to only the applicaons required for business purposes on the default ports.
Use the same method to create granular allow rules for each user group (if required, you can
do this for individual users as well), so that each group can only use legimate applicaons
running on default ports to access only the sets of servers that they have business reasons to
access. For example, allow only the group of Finance users who need access to servers that
contain PCI to access those servers, using only the sanconed finance applicaons required to
accomplish business goals.

Similar to the allow rule for engineering user access to data center servers, this rule allows
users in the finance-users and accounng-users groups to use only the specified applicaons
to access only the servers in the Fin-Servers dynamic address group. The rule applies the best
pracce security profiles to allowed traffic and logs acvity.

STEP 4 | Allow targeted, limited data center access to contractors, partners, customers, and other
third-pares.
This rule shows how to ghtly control access for third-party users so that they can use only the
applicaons they need on only the servers they need. For example, a company hires a group of
SAP developer contractors. The SAP developers need to access the SAP database in the data
center and make SQL queries. However, SQL also runs on producon databases that the SAP
developers should not access. The company needs to control three access vectors:
• User group—SAP developer contractors.
• Applicaons—MS-SQL and SAP.
• Servers—SAP database servers only. Deny all other data center server access.
The combinaon of User-ID to isolate the SAP contractor user group, App-ID to limit the group
to using only the necessary applicaons, and a dynamic address group that limits access to only

Data Center Best Pracce Security Policy Version Version 10.1 74 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

the SAP database servers in the data center enables the company to provide exactly the access
the SAP contractors need to perform their dues, but no more.

To create this rule:


• Specify the Source Zone and User to limit access to users in the sap-contractors group
coming from the Contractors zone.
• Restrict the Desnaon to the SAP database servers (SAP DB Server dynamic address
group) in the SAP-Infra zone.
• Allow the SAP contractors to use only the applicaons they need to perform their business
dues, on the default ports. In this example, the rule allows the ms-sql-analysis-service,
mssql-db, mssql-mon, and sap applicaons.
Granular security policy allow rules prevent all but the access required for business purposes
and reduce risk by reducing the aack surface. Create similar allow rules for each third-party
group that requires access to your data center.
Instead of trusng third-party users and companies to secure their credenals, require mul-
factor authencaon (MFA; Create User-to-Data-Center Authencaon Policy Rules) to
prevent access if aackers steal credenals or otherwise compromise third-party systems. MFA
authencaon would have prevented several high-profile data breaches that occurred over the
past several years.

Verify that only the applicaons you explicitly allowed in the security policy rules are running
by viewing the predefined Applicaons report (Monitor > Reports > Applicaon Reports >
Applicaons). If you see unexpected applicaons in the report, review the applicaon allow rules
and refine them so that they don’t allow the unexpected applicaons.

Create User-to-Data-Center Authencaon Policy Rules


Authencaon Policy rules force users to prove that they are who they claim to be before they
can access data center services, applicaons, and other resources. Authencaon is especially
important for protecng your most valuable assets because if an aacker steals credenals and
authencates with the firewall, the aacker may be able to access and compromise any asset in
your data center.
For access to sensive servers and for third-party user access to servers (for example, SAP
development contractors accessing SAP servers in the data center), implement Mul-Factor
Authencaon (MFA) to prevent aackers from using stolen credenals to access those systems.
An Authencaon policy with MFA would have prevented a number of successful high-profile
breaches over the past several years.
Before you create Authencaon Policy rules (Policies > Authencaon), you must configure
Authencaon Policy dependencies to e the authencaon method, the authencaon
type, how to access the authencaon server, and the use of Authencaon Portal to an
Authencaon Policy rule that specifies who can authencate on which servers using what
services.

Data Center Best Pracce Security Policy Version Version 10.1 75 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

STEP 1 | Authencate employee user groups and individuals that have legimate business reasons to
use data center servers.
This rule show how to authencate user groups so that they can access services required for
their business acvies on the necessary servers. For example, engineers need to authencate
before they can access development servers and applicaons.

To create this rule:


• Specify the engineering user groups that need to authencate before they can access
engineering servers in the data center, in this example, api-users and engg-users.
• Apply authencaon for these user groups to data center development server access
requests by creang a dynamic address group (Dev-Servers) for them and seng it as the
Desnaon Address.
• Apply the Authencaon rule to the services engineering groups need to use for business
purposes, in this example Perforce, rdp, service-hp, service-hps, and ssh (developers
may need to use SSH and RDP to access Linux servers and should authencate before being
allowed to access those servers). The services in your authencaon rules depend on the
services that the groups need to use.
• Configure an Authencaon Enforcement Object (Auth-Dev-Servers) that specifies the
authencaon method and the Authencaon Profile and add it to the rule.
• Log acvity so that you can track and analyze rule violaons, which may indicate an
aempted aack.
Another authencaon use case is when a group requires access to a parcular set of services.
For example, Finance Department users need access to sensive Payment Card Informaon
(PCI) using parcular services and should authencate before being granted access. To
authencate users for those services, this rule uses a custom Service Group (Objects > Service
Groups) that includes only services for which the firewall should authencate Finance users.

To create this rule:


• Specify the user groups that need to authencate before they can access finance servers in
the data center, in this example, accounng-users and finance-users.
• Apply authencaon for these user groups to data center finance server access requests by
creang a dynamic address group (Fin-Servers) for them and seng it as the Desnaon
Address.
• Apply the authencaon rule to the services that Finance users need to use for business
purposes, in this example service-hp, service-hps, and the services defined in the custom

Data Center Best Pracce Security Policy Version Version 10.1 76 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

service group Custom-Finance-Srvrs-Services, so that users must authencate before they


can access these services.
• Configure an Authencaon Enforcement Object (Auth-Finance-Servers) that specifies the
authencaon method and the Authencaon Profile and add it to the rule.
• Log acvity so that you can track and analyze rule violaons, which may indicate an
aempted aack.

STEP 2 | Authencate contractors, partners, customers, and other non-employee groups that require
data center access.
This rule requires MFA for third-party user groups such as contractors, partners, and customers
because you have less control over the business and security pracces of their companies and
personnel than you do over your employees. Requiring these users to authencate with at
least two factors protects your data center against credenal the at a third-party company.

To create this rule:


• Apply the Authencaon rule to the services SAP contractors need to use for business
purposes. Create a custom service group (Sap-Services) to define the ports on which SAP
contractors can authencate and add other necessary services, in this example, service-hp
and service-hps.
• Configure an Authencaon Enforcement Object (Auth-SAP-Servers) that specifies the
authencaon method and the Authencaon Profile and add it to the rule. In this case,
the authencaon type must be one that supports MFA, and you must Add an MFA server
profile to the Authencaon Profile (Factors tab) and perform the rest of the steps to
configure MFA.
Configure MFA to authencate all users and user groups that access sensive systems to
protect against aackers with stolen credenals.
• Log acvity so that you can track and analyze rule violaons, which may indicate an
aempted aack.

STEP 3 | Authencate users who need specialized access, such as IT personnel who need secured
access to data center servers for management and maintenance.
This rule shows you how to configure authencaon for users who have privileged accounts,
which grant administrave access to crical systems. Because compromising the credenals
of a privileged user hands an aacker the keys to your data center kingdom and its valuable
assets, you need to protect against stolen credenals by requiring at least two factors of

Data Center Best Pracce Security Policy Version Version 10.1 77 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

authencaon to ensure that only legimate users are granted access. This example shows
how to authencate the right IT users for access to data center server management interfaces.

To create this rule:


• Specify the privileged account users who need to authencate before they can access data
center server management interfaces, in this example, the it-superusers group.
• Apply authencaon for the user group to data center management interface access
requests by creang a dynamic address group (IT-Server-Management stac address group)
for them and seng it as the Desnaon Address.
• Apply the Authencaon rule to the services privileged IT personnel need to use for
business purposes, in this example, the custom service group Custom-IT-Ports, which
idenfies all of the server management ports (which should be placed on the same subnet).
• Configure and apply an Authencaon Enforcement Object (Auth-IT-Server-Mgmt in
this example) that enforces requiring MFA (two factors) for authencaon. Add an MFA
server profile to the Authencaon Profile (Factors tab) and perform the rest of the steps to
configure MFA. Using MFA is crical because you need to be certain of the identy of each
IT user who has a privileged account since they have access to device management.
To further reduce the opportunity for an aacker to compromise the data center using
stolen credenals or an opportune moment when a workstaon is unaended but
not locked, when you configure MFA, configure authencaon mestamps for the
authencaon factors. With valuable data center assets, it’s best to priorize securing
services and applicaons.
• Log acvity so that you can track and analyze rule violaons.
IT personnel also manage switches, routers, and other devices in the data center. If the same
group of IT users manages those resources, you can add them to the desnaon zone and
address so that the rule authencates IT superusers before they can access the management
interfaces of those devices. If different IT user groups manage different sets of data center
resources, create separate, ght security policy rules and corresponding authencaon policy
and decrypon policy rules for each user group.

Do not send credenals in cleartext. For example, if you use RADIUS, use a supported
EAP method to transport credenals securely inside TLS.

Create User-to-Data-Center Decrypon Policy Rules


Create Decrypon policy rules for traffic that enters the data center from the user populaon
to provide visibility so that you can inspect the traffic and safeguard your most valuable assets.
When you create a Security policy rule that allows a group of users (or a parcular user) access to
a set of data center servers, create a decrypon policy rule to decrypt that traffic.
Because the data center houses your most valuable assets, decrypt all the data center traffic you
can decrypt. Start by decrypng traffic to the most crical servers, decrypng high-risk traffic
categories, and decrypng traffic from the least trusted network segments (for example, priorize
decrypng third-party traffic from partners, customers, or contractors over decrypng traffic

Data Center Best Pracce Security Policy Version Version 10.1 78 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

from a trusted internal segment), and then expand the effort unl you have applied decrypon to
traffic desned to all of your data center assets. Decrypt as much traffic as you can while retaining
acceptable performance.

Exclude Unsuitable Traffic from Data Center Decrypon. Regulaons and compliance
over personal informaon differ from country to country and even within country regions.
Different companies may have different compliance rules about personal informaon.
Decrypt as much traffic as you can, but if your data center houses informaon that
regulaons or company rules exempt from decrypon, don’t decrypt that traffic.

In Create User-to-Data-Center Applicaon Allow Rules, we created Security policy rules that
allow DNS access, allow engineering users to access engineering development servers, allow SAP
contractor developers to access only the SAP development servers, and allow a parcular set of
IT users data center server management access. Here we create decrypon policy rules (Policies >
Decrypon) to decrypt the traffic that these rules allow.
The decrypon policy rules share some common elements in regard to these traffic flows:
• When you create a Decrypon policy rule, the objecve is to decrypt traffic so that a Security
policy rule can examine it and allow or block it based on policy. To accomplish that, the
Decrypon policy rule must use the same source zone(s) and user(s) as the analogous security
policy rule, and the same desnaon zone and address (oen defined by a dynamic address
group so that as you add or remove servers, you can update the firewall without a commit
operaon). Defining the same source and desnaon in the Security policy and in the
Decrypon policy applies both policies to the same traffic.
• The Acon for all of these rules is decrypt, except in the case of sensive personal informaon
as shown in Step 4.
• For each rule, configure decrypon logging and log forwarding. Log as much decrypon traffic
as your firewall resources permit.
• The decrypon rules that use SSL Inbound Inspecon to examine incoming traffic require the
appropriate server cerficate.
• All of these decrypon rules use the Best Pracce data center decrypon profile shown in
Create the Data Center Best Pracce Decrypon Profiles.
STEP 1 | Decrypt allowed traffic from employee user groups to data center servers.
This rule shows how to decrypt traffic from a user group to the data center servers that the
group is allowed to access to provide visibility into that traffic. For example, the applicaon
allow rules we created include a Security policy rule that allows engineering users to access
development servers in the data center. To protect the development servers, decrypt incoming
traffic so that the firewall can inspect it and apply threat prevenon profiles.

To create this rule:


• Specify the same source and desnaon as in the analogous security policy rule. In this
case, the Source users are the api-users and engg-users user groups in the Engineering-

Data Center Best Pracce Security Policy Version Version 10.1 79 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Users zone, and the Desnaon is the servers specified in the Dev-Servers dynamic address
group in the Engineering-DC-Infra zone.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Inbound
Inspecon. Specify the server cerficate for the development servers and apply the data
center best pracce Decrypon Profile to apply SSL Inbound Inspecon and SSL Protocol
Sengs to the traffic.
Create a similar Decrypon policy rule for allowed data center traffic of each user group (or
individual user, if applicable) based on the source zone and user group (or user) and on the
desnaon zone and server group (as defined by the dynamic address group membership).

STEP 2 | Decrypt allowed traffic from contractors, partners, customers, and other third-pares.
This rule shows how to decrypt from third-party groups to the data center servers they are
allowed to access. For example, the allow rules include a security policy rule that allows limited
access for SAP developer contractors to SAP database servers in the data center. Decrypt
incoming traffic so that the firewall can inspect it, apply threat prevenon profiles to it, and
protect the SAP data center servers.

To create this rule:


• Specify the same source and desnaon of the traffic to decrypt as in the analogous
security policy rule. In this case, the Source users are the sap-contractors user group in
the Contractors zone, and the Desnaon is the servers specified in the SAP DB Servers
dynamic address group in the SAP-Infra zone.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Inbound
Inspecon. Specify the server cerficate for the development servers and apply the data
center best pracce Decrypon Profile to apply SSL Inbound Inspecon and SSL Protocol
Sengs to the traffic.
Create a similar Decrypon policy rule for each third-party group’s allowed data center traffic
based on the source zone and user group and the desnaon zone and server group (as
defined by the dynamic address group membership).

STEP 3 | Decrypt privileged allowed access to data center servers (except traffic pertaining to personal
informaon if regulaons or compliance rules prohibit it).
This rule shows how to decrypt traffic for privileged access because you should decrypt
as much traffic as possible to provide the visibility necessary to defend the data center, no
maer how much you trust the users. If you don’t decrypt allowed traffic, you can’t apply
threat prevenon profiles, and if the traffic conceals malware or other threats, you won’t see

Data Center Best Pracce Security Policy Version Version 10.1 80 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

them. This example references the Security Policy allow rule we created previously to provide
management interface access to data center servers for IT superusers.

If the IT group that manages and maintains data center servers uses SSH, you can’t
decrypt the SSH traffic. You can configure SSH Proxy to block SSH tunnels and
prevent SSH from tunneling potenally malicious content and applicaons. If the
IT group uses SSL, create a Decrypon Policy rule using SSL Forward Proxy instead
of SSL Inbound Inspecon. The reason is that SSL Inbound Inspecon requires the
server cerficate to perform decrypon. Because IT manages many data center
servers, creang SSL Inbound Inspecon rules for each server is onerous and difficult to
manage. SSL Forward Proxy decrypon scales beer in this use case.

The following example shows the Decrypon policy rule for the SSL Forward Proxy use case.

To create this rule:


• Specify the same source and desnaon of the traffic to decrypt as in the analogous
security policy rule. In this case, the Source users are the it-superusers user group in the IT-
Users zone, and the Desnaon is the servers specified in the IT-Server-Management stac
address group in the IT-server-access-DC zone.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Forward
Proxy. Apply the data center best pracce Decrypon Profile to apply SSL Forward Proxy
and SSL Protocol Sengs to the traffic.
If other groups require privileged access, create a similar type of Decrypon Policy rule for
each group.
IT personnel also manage switches, routers, and other devices in the data center. If the same
group of IT users manages those resources, you can add them to the desnaon zone and
address so that the rule decrypts traffic for connecons to the management interfaces of
those devices. If different IT user groups manage different sets of data center resources, create

Data Center Best Pracce Security Policy Version Version 10.1 81 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

separate, ght security policy rules and corresponding decrypon and authencaon policy
rules for each user group.
The next example shows the Decrypon policy rule for the SSH Proxy use case. You may also
choose not to decrypt the traffic instead of using SSH Proxy decrypon.

To create this rule:


• The traffic source and desnaon are the same as for the preceding SSL Forward Proxy use
case example rule.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSH Proxy.
Apply the data center best pracce Decrypon Profile to apply SSH Proxy and SSL Protocol
Sengs to the traffic.
IT personnel also manage data center switches, routers, and other devices. If the same
group of IT users manages those resources, you can add them to the desnaon zone and
address so that the rule decrypts traffic for connecons to the management interfaces of
those devices. If different IT user groups manage different sets of data center resources,
create separate, ght security policy rules and corresponding decrypon and authencaon
policy rules for each user group.

STEP 4 | Do not decrypt sensive personal informaon if prohibited by regulaons or compliance


rules.
This rule shows how to create a policy-based decrypon exclusion if you need to except traffic
from decrypon for regulatory or compliance reasons. This example references the Security
Policy allow rule we created previously to provide Finance server access for Finance users. If
regulaons or compliance permit you to decrypt this traffic, decrypt it so that the firewall can
see the traffic and protect against threats.

To create this rule:


• Specify the same source and desnaon of the traffic to decrypt as in the analogous
security policy rule. In this case, the Source users are the accounng-users and finance-
users user groups in the Finance-Users zone, and the Desnaon is the servers specified in
the Fin-Servers dynamic address group in the Finance-DC-Infra zone.
• On the Opons tab, set the Acon to No Decrypt. Apply the data center best pracce No
Decrypon profile to protect against cerficate issues.

Do not apply a No Decrypon profile to TLSv1.3 traffic because the cerficate


informaon is encrypted, so the firewall cannot block sessions based on cerficate
informaon.

Data Center Best Pracce Security Policy Version Version 10.1 82 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Define the Inial Internet-to-Data-Center Traffic


Security Policy
As with the other data center traffic flows, ghtly control traffic flowing from the internet to
the data center with applicaon allow security policy rules so that no traffic using unknown or
unsanconed applicaons can enter the data center. In addion, protect the data center web
servers from denial-of-service (DoS) aacks by applying DoS Protecon policy rules (with DoS
Protecon profiles) to external traffic desned for the data center web server er.
• Internet-to-Data-Center Traffic Security Approach
• Create Internet-to-Data-Center Applicaon Allow Rules
• Create Internet-to-Data-Center DoS Protecon Policy Rules
• Create Internet-to-Data-Center Decrypon Policy Rules

Internet-to-Data-Center Traffic Security Approach


The tradional legacy approach to securing data center traffic flowing to the data center from
the internet leaves valuable assets exposed to risk, while the best pracce approach protects
your valuable assets. The major risks from traffic entering the data center are inadvertently
downloading malware from an infected external server or inadvertently placing malware on an
external server from a compromised data center server.

The Tradional Risk The Best Pracce Approach


Approach

Create port- Malicious applicaons access Applicaon allow rules prevent


based security the network by spoofing port applicaons from running on non-
policy. numbers, tunneling through a standard ports. Log and monitor allow
port, or using port hopping to list violaons.
avoid detecon.

Data Center Best Pracce Security Policy Version Version 10.1 83 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

The Tradional Risk The Best Pracce Approach


Approach
When you transion
from port-based to
applicaon-based rules,
in the rulebase, place
the applicaon-based
rule above the port-
based rule it will replace.
Reset the policy rule hit
counter for both rules.
If traffic hits the port-
based rule, its policy rule
hit count increases. Tune
the applicaon-based
rule unl no traffic hits
the port-based rule for
a period of me, then
remove the port-based
rule.

An Intrusion An IPS is an in-band detecon In-band on the firewall, use Palo


Prevenon and prevenon system, while an Alto Networks App-ID, User-ID, and
System (IPS) is IDS is an out-of-band detecon Content-ID to create applicaon allow
oen deployed system. Deploying an IPS as an list security policies that ghtly control
as an Intrusion IDS takes intrusion detecon access. Apply the security profiles to
Detecon System out of the direct communicaon stop known and new threats.
(IDS). path between the source and
the desnaon, so real-me
prevenon can’t occur and
threats can enter the data
center.

A web applicaon An aacker places command- Stop aackers from placing C2


firewall is and-control (C2) soware onto soware on data center endpoints
sufficient to a compromised data center simply by assigning the strict An-
protect the data endpoint, opening the network Spyware security profile to the security
center. to aack and potenally policy rule that controls the traffic. This
serving client-side exploits in a profile is one of the firewall’s included
watering-hole aack. features, so it costs you nothing extra
to apply this protecon.

Create Internet-to-Data-Center Applicaon Allow Rules


The greatest risks from traffic entering the data center from the internet are inadvertently
downloading malware from an infected external client or inadvertently placing malware on an
external server if a client pulls data from a compromised server in your data center. Protect traffic

Data Center Best Pracce Security Policy Version Version 10.1 84 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

from the internet to the data center so that you don’t inadvertently download malware that
takes advantage of server vulnerabilies or allow a client to download malware from one of your
company’s servers that could infect partners, customers, or wind up on a website used by your
industry (serving a watering-hole aack).
Ensure that the source of traffic to the data center doesn’t come from malicious IP addresses or
other potenally risky sources, and only allow applicaons required for business purposes. Don’t
allow unnecessary (and especially unknown) applicaons in the data center. To do these things:
• Create allow rules that control the sanconed and allowed applicaons that external devices
can use to communicate with your data center.

Tag all sanconed applicaons with the predefined Sanconed tag. Panorama
and firewalls consider applicaons without the Sanconed tag as unsanconed
applicaons.
• Create an External Dynamic List to idenfy bad IP addresses and use it to prevent them from
accessing your data center.
• Create a custom applicaon for any proprietary applicaon so that you can idenfy the
applicaon and apply security to it.
If you have exisng Applicaon Override policies that you created solely to define custom
session meouts for a set a of ports, convert the exisng Applicaon Override policies to
applicaon-based policies by configuring service-based session meouts to maintain the
custom meout for each applicaon and then migrang the rule the an applicaon-based rule.
Applicaon Override policies are port-based. When you use Applicaon Override policies to
maintain custom session meouts for a set of ports, you lose applicaon visibility into those
flows, so you neither know nor control which applicaons use the ports. Service-based session
meouts achieve custom meouts while also maintaining applicaon visibility.
• Apply the best pracce Security profile group, which consists of the best pracce Security
profiles to allow rules to protect against malware, vulnerabilies, C2 traffic, and known and
unknown threats.
• Log all allowed traffic at session end to track and analyze rule violaons. Forward logs to log
servers and when applicable, forward log emails to appropriate administrators.
Order the Data Center Security Policy Rulebase shows you how to order these rules with all of the
other rules we create for the other three data center traffic flows and the block rules so that no
rule shadows another rule.

To apply consistent security policy across mulple data centers, you can reuse templates
and template stacks so that the same policies apply to every data center. The templates
use variables to apply device-specific values such as IP addresses, FQDNs, etc., while
maintaining a global security policy and reducing the number of templates and template
stacks you need to manage.

Allow sanconed applicaon traffic from vendors, contractors, and customers, restricted to only
the necessary applicaons.
This rule shows how to secure applicaon traffic arriving at the data center from external
sources by ghtly controlling the allowed applicaon(s), allowing them only on the default port,
and blocking sources that you know are bad using an External Dynamic List to idenfy known
bad IP addresses.

Data Center Best Pracce Security Policy Version Version 10.1 85 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

To create this rule:


• Prevent known bad sources from aempng to access the data center. Use the Negate
opon in the Security Policy rule Source Address to block connecons from bad IP
addresses. This example uses an External Dynamic List (Bad IPs List)) to idenfy known bad
IP addresses and block them. (The strikethrough text in the source address indicates that it
is negated rather than allowed.)
• Restrict the applicaon(s) to only the applicaon(s) required for business purposes and
allow them to run only on their default ports (applicaon-default) to prevent evasive
malware from aempng to run on non-standard ports. In this example, the vendor uses a
proprietary applicaon called Acme. We created a custom applicaon to idenfy the Acme
proprietary applicaon so that the firewall can classify the traffic and apply the appropriate
Security policy.
• Restrict the desnaon for Acme applicaon traffic to the Web-Servers dynamic address
group in the Web-Server-Tier-DC zone. If the desnaon address isn’t in the web server
er, the firewall drops the traffic.
Verify that only the applicaons you explicitly allowed in the security policy rules are running
by viewing the predefined Applicaons report (Monitor > Reports > Applicaon Reports >
Applicaons). If you see unexpected applicaons in the report, review the applicaon allow rules
and refine them so that they don’t allow the unexpected applicaons.

Create Internet-to-Data-Center Decrypon Policy Rules


Create Decrypon policy rules to provide visibility into traffic that enters the data center from the
internet so that you can apply Security policy to that traffic. When you create a Security policy
rule that allows access to a set of data center servers, create a decrypon policy rule to decrypt
that traffic. In Create Internet-to-Data-Center Applicaon Allow Rules, we created a Security
policy rule that allows access from internet to the web server er in the data center, using only
allowed applicaons. Here we create a decrypon policy rule ( Policies > Decrypon) to decrypt
the traffic that this rule allows.
To decrypt traffic so that a Security policy rule can examine it and allow or block it based on policy,
the Decrypon policy rule must use the same source zone(s) and user(s) as the analogous security
policy rule, and the same desnaon zone and address (oen defined by a dynamic address group
so that as you add or remove servers, you can update the firewall without a commit operaon).
Defining the same source and desnaon in the Security policy and in the Decrypon policy
applies both policies to the same traffic.
The decrypon rule uses the Best Pracce data center decrypon profile shown in Create the
Data Center Best Pracce Decrypon Profiles.
For each rule, configure decrypon logging and log forwarding. Log as much decrypon traffic as
your firewall resources permit.
STEP 1 | Decrypt allowed traffic from the internet to data center web servers.
This rule shows how to decrypt traffic from externally iniated connecons to the data center.
For example, the applicaon allow rules we created enable external traffic access to the data

Data Center Best Pracce Security Policy Version Version 10.1 86 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

center web serves, using only certain applicaons. To protect the data center web servers,
decrypt traffic so the firewall can inspect it and apply threat prevenon profiles.

To create this rule:


• Specify the same source and desnaon as in the analogous security policy rule. In this
case, the Source is the L3-External zone, and the Desnaon is the servers specified in the
Web-Servers dynamic address group in the Web-Server-Tier-DC zone.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Inbound
Inspecon. Specify the server cerficate for the web servers and apply the data center best
pracce Decrypon Profile to apply SSL Inbound Inspecon and SSL Protocol Sengs to
the traffic.

STEP 2 | Create similar Decrypon policy rules for traffic from the internet to any other server group,
if such access is allowed, and for the other applicaons you allow.

Create Internet-to-Data-Center DoS Protecon Policy Rules


One method aackers use to disrupt a network is a Denial-of-Service (DoS) aack intended to
overwhelm targeted systems that are connected to the internet, take them down, and make them
unavailable to all of your legimate users and services. Data center web servers are an aracve
target because taking them down prevents most legimate access to the data center.
Protect the data center web server er by applying a classified DoS Protecon Policy to internet
traffic desned for those servers. A classified DoS Protecon policy applies a classified DoS
Protecon Profile that controls the number of incoming connecons to the traffic defined in the
policy.
In addion, configure packet buffer protecon for each zone to protect the firewall from single-
session DOS aacks that can overwhelm the firewall’s packet buffer and cause legimate traffic to
drop, especially on firewalls that protect crical services.
STEP 1 | Create a classified DoS Protecon Profile that protects data center web servers from DoS
aacks by liming the number of connecons-per-second to prevent a SYN flood aack.
This DoS Protecon profile limits the number of connecons-per-second (CPS) for the traffic
defined in the DoS Protecon Policy rules to which you aach the profile, to prevent a DoS
aack from taking down your web servers. The profile sets progressive CPS thresholds to alert
you, to acvate Random Early Drop (RED) packet drop, and to block new connecons, as well

Data Center Best Pracce Security Policy Version Version 10.1 87 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

as a duraon during which new connecons remain blocked. The CPS thresholds you configure
to protect your data center web servers depends on the capacity of your web servers.

To create this profile:


• At Objects > Security Profiles > DoS Protecon, Add a classified DoS Protecon Profile.
• Name the profile, select Classified as the profile Type, set the CPS values to alert ( Alarm
Rate), acvate RED ( Acvate Rate), begin blocking new sessions ( Max Rate), and set the
amount of me in seconds to block new sessions ( Block Duraon) when the CPS rate
reaches the Max Rate threshold.

If you don’t use protocols such as UDP or other IP protocols, restrict them using
a combinaon of Security policy rules to allow applicaons and Zone Protecon
Profiles to block unused protocols by seng flood protecon CPS to zero packets for
protocols you want to block.

STEP 2 | Create a classified DoS Protecon policy rule to define the servers you want to protect from
a DoS aack and aach the DoS Protecon profile to it.
This rule prevents a SYN flood aack from taking down your data center web server er. This
example applies the classified DoS Protecon profile to external traffic allowed to connect to
the web server er.

To create this rule:


• To apply DoS protecon to traffic desned for the web server er, the DoS Protecon
policy must apply to the same traffic as the Security Policy rule that allows the traffic. In this
example, this DoS rule protects the traffic we allowed in Create Internet-to-Data-Center
Applicaon Allow Rules.
• On the Opon/Protecon tab, specify the web services ( service-hp and service-hps),
set the Acon to protect to apply the DoS Protecon profile’s SYN flood thresholds to the
traffic, set the Log Forwarding method (assuming that you have configured log forwarding),
and select the classified DoS Protecon profile we configured for the traffic in the preceding
step ( Internet to DC).
To protect against SYN flood aacks from internal sources, create a separate DoS Protecon
policy rule that specifies your internal zones as the source zone instead of L3-External.

Data Center Best Pracce Security Policy Version Version 10.1 88 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Creang separate rules for external and internal aack sources provides separate reporng
that makes invesgang aack aempts easier.

Data Center Best Pracce Security Policy Version Version 10.1 89 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Define the Inial Data-Center-to-Internet Traffic


Security Policy
Depending on your data center architecture, servers in the data center may reach out to the
internet to retrieve soware updates or to check server cerficate revocaon status. The
data center is a great place for adversaries to hide because security plans oen focus on user
communicaon and overlook servers that communicate with the internet. When data center
servers iniate communicaon directly with the internet, you need to protect against several
security risks:
• Data exfiltraon—Aackers use legimate applicaons such as FTP or HTTP, or other methods
such as DNS tunneling, to steal data. Create an applicaon security policy rule allow list that
allows only the applicaons required for server updates so that all other applicaons are
blocked, even if they are legimate applicaons in other circumstances. Loose applicaon rules
present opportunies to aackers.
• Command-and-control (C2) using legimate applicaons—If data center servers are allowed to
communicate with the internet using legimate applicaons that are not for soware updates,
aackers could use those otherwise legimate applicaons for C2 acvies. For example,
allowing web-browsing on non-standard ports creates opportunies for aackers. Servers
should only be allowed to communicate w/the internet using only the specific applicaons
required for soware updates on their default ports, and no other applicaons, even if those
applicaons are legimate and sanconed for other uses.
• Downloading addional malware—If an aacker compromises a data center server, the
malware on the server may download more malware from the internet through a phone-home
or other mechanism. A strict allow rule that allows communicaon only with the appropriate
update servers using only the necessary update applicaons prevents aackers from contacng
websites that house malware and from exfiltrang data. In addion, install Cortex XDR Agent
on the data center servers (and all of your endpoints) to prevent malware that already resides
on a server from execung.
• Data-Center-to-Internet Traffic Security Approaches
• Create Data-Center-to-Internet Applicaon Allow Rules
• Create Data-Center-to-Internet Decrypon Policy Rules

Data-Center-to-Internet Traffic Security Approaches


The tradional legacy approach to securing data center traffic flowing to the internet leaves
valuable assets exposed to risk, while the best pracce approach protects your valuable assets.

The Tradional Risk The Best Pracce Approach


Approach

Create port- Port-based and IP-based Create strict applicaon-based allow rules
based rules and/ rules can’t control which that allow only data center servers that
or IP-based rules, applicaons to allow to retrieve updates to use only legimate
which provide connect to the internet. If a applicaons to communicate only with
sufficient security

Data Center Best Pracce Security Policy Version Version 10.1 90 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

The Tradional Risk The Best Pracce Approach


Approach
in the trusted port is open, any applicaon legimate update servers. Log and monitor
network. can use the port. allow rule violaons.

When you transion from


port-based to applicaon-
based rules, in the rulebase,
place the applicaon-based
rule above the port-based
rule it will replace. Reset the
policy rule hit counter for
both rules. If traffic hits the
port-based rule, its policy rule
hit count increases. Tune the
applicaon-based rule unl
no traffic hits the port-based
rule for a period of me, then
remove the port-based rule.

Data center Malware or command- Decrypt all traffic from the data center
servers only reach and-control soware to the internet. Create a custom URL
out to trusted that is already in the data categories that defines the URLs data
servers such as center may aempt to center servers are allowed to contact and
update servers, communicate with external use it in Security policy to limit internet
so decrypng servers to download more access to external servers. Use the same
that traffic isn’t malware or exfiltrate data. custom URL in Decrypon policy to
necessary. decrypt traffic to those external servers.

Mix blocking A conglomeraon of The Palo Alto Networks suite of


and alerng individual tools leaves coordinated security tools works together
threat prevenon security holes for aackers to plug security holes and prevent aacks.
profiles from and may not work together
mulple vendors. well.

Create Data-Center-to-Internet Applicaon Allow Rules


The main use case for data center servers iniang connecons to external servers on the internet
is to update soware or to obtain cerficate status. The greatest risk is connecng to the wrong
server, especially for Linux updates because there are many third-party URLs to which you may
inadvertently connect. Ensure that your data center servers receive updates from legimate
update servers, using only the required applicaons on their default ports.
To do this, create strict applicaon allow rules that limit the external servers to which data center
servers connect and the applicaons that data center servers use when connecng to external
servers. Tag all sanconed applicaons with the predefined Sanconed tag. (Panorama and
firewalls consider applicaons without the Sanconed tag as unsanconed applicaons.) A strict
applicaon allow rule set disrupts potenal aacks by:

Data Center Best Pracce Security Policy Version Version 10.1 91 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

• Prevenng malware that is already on a data center server from connecng to a compromised
external server (phoning home) and downloading addional data because the allow rules don’t
allow connecons to those servers.
• Prevenng aackers from using legimate applicaons such as FTP, HTTP, or DNS tunneling to
exfiltrate data or using legimate applicaons such as web-browsing on non-standard ports for
command-and-control (C2) operaons because the allow rules don’t allow data center servers
to communicate with the internet using those applicaons. An addional way to help prevent
exfiltraon is to use the File Blocking profile’s Direcon control to block outbound update files
so you only allow downloading for soware update files.
Create a strict allow rule for each applicaon that requires soware updates from a different set
of external servers. In many cases, App-ID alone isn’t enough to protect data center servers. For
example, for Linux server updates, it’s not enough to limit traffic to an update applicaon such as
yum or apt-get because that doesn’t prevent connecng to illegimate servers. The best pracce
is to find the URLs that data center servers need to connect to, create custom URL categories
(Objects > Custom Objects > URL Category) that specify the websites to use, and combine them
with App-ID in Security policy rules. The combinaon of App-ID and custom URL categories locks
down the external servers with which the data center servers can connect by prevenng the use
of illegimate applicaons and prevenng connecons to update servers that aren’t in the custom
URL category. For example, in a Security policy rule that allows data center servers to connect to
CentOS update servers, you could create a custom URL category called CentOS-Update-Servers
and add the CentOS update sites your servers use to the custom category.

To find out the URLs of legimate Linux update servers and other update servers, work
with soware engineering, development operaons, and other groups that update
soware to understand where they go to get updates. You can also log web browsing
sessions, collect the URLs to which developers connect, and then take the URLs to
engineering to filter out the right URLs for the Security policy.

Don’t use the URL Filtering Profile (PAN-DB URL Filtering) in Security policy rules for data
center servers that communicate with the internet because you don’t want to allow all
update servers. Restrict communicaon so that data center servers only reach out to the
parcular servers from which they retrieve updates.

In addion, all allowed communicaon should occur on the standard ports for each applicaon. No
applicaons should run on non-standard ports. As with all data center traffic, monitor allow rule
violaons because violaons indicate either that you need to update the security policy to allow
legimate traffic or that an adversary is in or is aempng to enter the network.
Order the Data Center Security Policy Rulebase shows you how to order these rules with all of the
other rules we create for the other three data center traffic flows and the block rules so that no
rule shadows another rule.

To apply consistent security policy across mulple data centers, you can reuse templates
and template stacks so that the same policies apply to every data center. The templates
use variables to apply device-specific values such as IP addresses, FQDNs, etc., while
maintaining a global security policy and reducing the number of templates and template
stacks you need to manage.

Each of the following allow rules:

Data Center Best Pracce Security Policy Version Version 10.1 92 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

• Has the best pracce Security profile group aached, which consists of the best pracce
Security profiles. Using a Security profile group enables you to apply all of the best pracce
profiles to a rule at one me instead of specifying each profile individually. Security profile
groups make configuring protecon against malware, vulnerabilies, C2 traffic, and known and
unknown threats faster and easier.
• Logs traffic (at session end) so that you can track and analyze rule violaons and includes log
forwarding. Forward logs to log servers and when applicable, forward log emails to appropriate
administrators.
STEP 1 | Allow data center servers to access soware update servers.
This rule shows how to restrict access to soware update servers on the internet so that data
center servers communicate only with legimate, known servers and don’t communicaon
with other external update servers. This example allows engineering data center servers
to access CentOS update servers and restricts communicaon to using only the necessary
applicaons to establish connecons to only the right set of update servers.

To create this rule:


• Restrict the source of CentOS update requests to only the data center servers that
need to retrieve updates, in this example the Dev-Servers dynamic address group in the
Engineering-DC-Infra zone.
• Restrict the applicaon(s) that data center servers can use to communicate with external
update servers to only the required applicaon(s), in this example, yum for CentOS updates.

Data Center Best Pracce Security Policy Version Version 10.1 93 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Only allow the applicaon(s) to run on the default port to prevent evasive malware from
aempng to use non-standard ports.
• Create a custom URL category to define the URLs of the update servers to which the data
center servers can connect. In this example, the CentOS-Update-Servers custom URL
category defines the update server URLs that the data center servers can reach.
This combinaon of restricons also prevents aackers who have already compromised a data
center server from reaching other desnaons and using other applicaons to exfiltrate data or
download addional malware.
Similarly, a rule allowing the same servers to communicate with Microso Windows update
servers uses the same construcon.

The source zone and address are the same as in the preceding CentOS update rule. The
differences are:
• The custom URL category (Win-Update-Servers) contains the URL for Windows updates so
that contact with other URLs is denied.
• The applicaons pertain to Microso updates. In addion to the ms-update applicaon,
Microso updates require the ssl applicaon because ms-update depends on SSL. As with
the CentOS update rule, only standard ports are valid.
Some applicaons depend on other applicaons. For a given applicaon, you must allow all
dependent applicaons or the applicaon won’t work. The user interface shows applicaon
dependencies when you create a Security policy rule. For example, when you specify the

Data Center Best Pracce Security Policy Version Version 10.1 94 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

ms-update applicaon in the rule, the interface shows that ms-update depends on also
allowing SSL:

Click Add to Current Rule to add the selected applicaon(s) to the rule.

You can also use the Search funcon (Objects > Applicaons) to find applicaon
dependencies. For example, to find the dependencies for the ms-update applicaon,
search for ms-update, click the ms-update applicaon in the resulng applicaon
list, and then check the Depends on: field.

STEP 2 | Allow data center servers to access DNS and NTP update servers.
This rule shows how to restrict access to DNS and NTP update servers on the internet so that
data center servers communicate only with legimate, known servers. This example allows IT
data center servers to access DNS and NTP update servers and restricts communicaon to

Data Center Best Pracce Security Policy Version Version 10.1 95 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

using only the necessary applicaons to establish connecons to only the right set of update
servers.

To create this rule:


• Restrict the source of DNS and NTP update requests to only the data center servers that
need to retrieve updates, in this example the DNS-NTP-Servers dynamic address group in
the Engineering-DC-Infra zone.
• Restrict the applicaons that data center servers can use to communicate with these
external update servers to only the required applicaons, in this example, dns and ntp.
Allow the applicaons to run only on the default port to prevent evasive malware from
aempng to use non-standard ports.
• Create a custom URL category to define the URLs of the update servers to which the data
center servers can connect. In this example, the NTP-DNS-Update-Servers custom URL
category defines the update server URLs that the data center servers can reach.

STEP 3 | Allow data center servers to access cerficate authority servers to obtain the revocaon
status of digital cerficates and ensure that they are valid.
This rule enables data center servers to connect to an Online Cerficate Status Protocol
(OCSP) Responder (server) on the internet to check the revocaon status of authencaon
cerficates. An OCSP Responder provides the most recent cerficate status compared to
browser Cerficate Revocaon List (CRL) updates, which depend on the frequency of CRL
browser updates to keep up with cerficate revocaons, so the CRL is more likely to be out-
of-date than an OCSP Responder. When you configure a cerficate profile on the firewall, you
can set up CRL status verificaon as a fallback method for OCSP in case the OCSP Responder
is unreachable.

To create this rule:


• Restrict the source of cerficate revocaon check requests to only the data center servers
that need to check cerficate validaon, in this example the IT-Server-Management
dynamic address group in the IT-Infrastructure zone.
• Restrict the applicaons that data center servers can use to communicate with external
cerficate revocaon servers to only the required applicaons. This example secures the
connecon between data center servers and OCSP Responders, so the only applicaon
to specify is ocsp. Allow the applicaon to run only on the default port to prevent evasive
malware from aempng to use non-standard ports.

Verify that only the applicaons you explicitly allowed in the security policy rules are running
by viewing the predefined Applicaons report (Monitor > Reports > Applicaon Reports >
Applicaons). If you see unexpected applicaons in the report, review the applicaon allow rules
and refine them so that they don’t allow the unexpected applicaons.

Data Center Best Pracce Security Policy Version Version 10.1 96 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Create Data-Center-to-Internet Decrypon Policy Rules


Create Decrypon policy rules to provide visibility into traffic from data center servers to the
internet. Decrypt all traffic from data center servers to the internet. The only accounts iniang
connecons to the internet from inside the data center are service accounts and most of this
traffic pertains to soware updates, so there are no privacy issues to consider. It’s important to
decrypt and inspect this traffic because if an update server is compromised, data center servers
could download malware and propagate it through the soware update process. Inspecng the
traffic and applying the best pracce threat prevenon profiles protects your data center against
malware that could otherwise be downloaded from a legimate update server, using a legimate
applicaon.
In Create Data-Center-to-Internet Applicaon Allow Rules, we created Security policy rules that
allow data center servers to iniate connecons with internet update servers to update operang
system soware, DNS, NTP, and to check cerficates. Here we create analogous Decrypon
policy rules to decrypt the traffic that the update Security policy rules allow.

Do not decrypt traffic to cerficate revocaon servers (online responders). Online


Cerficate Status Protocol (OCSP) traffic usually uses HTTP, so the traffic is cleartext and
not encrypted. In addion, SSL Forward Proxy Decrypon may break the update process
because the firewall acts as a man-in-the-middle proxy and replaces the client cerficate
with a proxy cerficate, which the OCSP responder may not accept as valid.

The decrypon policy rules share some common elements in regard to these traffic flows:
• When you create a Decrypon policy rule, the objecve is to decrypt traffic so that a Security
policy rule can examine it and allow or block it based on policy. To accomplish that, the
Decrypon policy rule must use the same source zone(s) and user(s) as the analogous security
policy rule, and the same desnaon zone and address (oen defined by a dynamic address
group so that as you add or remove servers, you can update the firewall without a commit
operaon). Defining the same source and desnaon in the Security policy and in the
Decrypon policy applies both policies to the same traffic.
• The Acon for all of these rules is decrypt.
• For each rule, configure decrypon logging and log forwarding. Log as much decrypon traffic
as your firewall resources permit.
• All of these decrypon rules use the Best Pracce data center decrypon profile shown in
Create the Data Center Best Pracce Decrypon Profiles.
In many cases, the Decrypon policy rule examples include a custom URL category (Objects >
Custom Objects > URL Category) to narrow the scope of traffic to decrypt. Each Decrypon
policy rule uses the same custom URL category (and source and desnaon) as the analogous
Security policy rule so that the Decrypon and Security policies apply to exactly the same traffic.
The combinaon of App-ID and a custom URL category enables the firewall to decrypt only the
traffic the rule allows, which saves processing cycles by not decrypng traffic that the firewall will
block. (Decrypon must happen before Security policy rule evaluaon.)
STEP 1 | Decrypt traffic between data center servers and soware update servers on the internet.
This rule shows how to decrypt data center server soware update traffic to provide visibility
into threats that may be present on internet update servers so the firewall can block them. This
example decrypts allowed traffic between data center servers and CentOS update servers on

Data Center Best Pracce Security Policy Version Version 10.1 97 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

the internet based on the analogous applicaon allow rule we created in Create Data-Center-
to-Internet Applicaon Allow Rules.

To create this rule:


• Specify the same source and desnaon as in the analogous Security policy rule. In this
case, the source is the Dev-Servers dynamic address group in the Engineering-DC-Infra
zone, and the desnaon is the internet (L3-External zone).
• Specify the same custom URL category as in the analogous Security policy rule ( CentOS-
Update-Servers) to narrow the scope of decrypon to only traffic that the rule allows so
that the firewall doesn’t waste cycles decrypng traffic that it will drop.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Forward
Proxy. Apply the data center best pracce Decrypon Profile to apply SSL Forward Proxy
and SSL Protocol Sengs to the traffic.
Create a similar Decrypon policy rule for the allowed data center traffic of each group of data
center servers that needs to connect to internet update servers, based on the same source
and desnaon, and same custom URL category, as the analogous Security policy rule. For
example, the Decrypon policy rule for data center servers that need to communicate with
Microso Windows update servers, based on the analogous Security policy rule, looks like this:

STEP 2 | Decrypt traffic between data center servers and NTP and DNS update servers on the
internet.
This rule shows how to decrypt data center server NTP and DNS update traffic to provide
visibility into threats that may be present on these internet servers so the firewall can block
them. This example decrypts allowed traffic based on the analogous applicaon allow rule we
created in Create Data-Center-to-Internet Applicaon Allow Rules.

To create this rule:


• Specify the same source and desnaon as in the analogous Security policy rule. In this
case, the source is the DNS-NTP-Servers dynamic address group in the IT Infrastructure
zone, and the desnaon is the internet ( L3-External zone).
• Specify the same custom URL category as in the analogous Security policy rule ( NTP-DNS-
Update-Servers) to narrow the scope of decrypon to only traffic that the rule allows.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Forward
Proxy. Apply the data center best pracce Decrypon Profile to apply SSL Forward Proxy
and SSL Protocol Sengs to the traffic.

Data Center Best Pracce Security Policy Version Version 10.1 98 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Define the Inial Intra-Data-Center Traffic Security


Policy
Intra data center traffic flows between data center servers and applicaon ers. You could take
the viewpoint that everything inside the data center perimeter is trusted so you don’t need to
inspect that traffic. However, if an aacker compromises a data center server and the traffic
between applicaon ers doesn’t go through firewalls, the aacker can move laterally through
the data center to crical servers and download more malware, repurpose servers, and exfiltrate
data using legimate applicaons that have no place in the data center, as has happened in several
major breaches over the past several years.
The best defense against malware that gains a foothold in the data center is to secure the traffic
with strict, specific applicaon allow rules and to inspect the traffic with next-generaon firewalls
placed between applicaon ers.
In addion, allow no unknown applicaons in the data center. Unknown applicaons may indicate
that an adversary has gained access to your data center. Create custom applicaons for your
proprietary internal applicaons so that you can idenfy them with App-ID and apply security
to that traffic. If you don’t create custom applicaons for your proprietary applicaons, the
firewall sees them as unknown-tcp or unknown-udp traffic. The issue is that the firewall treats the
proprietary applicaons the same way it treats other unknown applicaons, and you should block
unknown applicaons because they may be an aacker’s tools. If you allow unknown applicaons
in your data center, you could be handing over the keys to your asset kingdom to an aacker.

For unknown commercial applicaons, you can submit a request to Palo Alto Networks to
create an App-ID.

If you have exisng Applicaon Override policies that you created solely to define custom session
meouts for a set a of ports, convert the exisng Applicaon Override policies to applicaon-
based policies by configuring service-based session meouts to maintain the custom meout for
each applicaon and then migrang the rule the an applicaon-based rule. Applicaon Override
policies are port-based. When you use Applicaon Override policies to maintain custom session
meouts for a set of ports, you lose applicaon visibility into those flows, so you neither know nor
control which applicaons use the ports. Service-based session meouts achieve custom meouts
while also maintaining applicaon visibility.
• Intra-Data-Center Traffic Security Approach
• Create Intra-Data-Center Applicaon Allow Rules
• Create Intra-Data-Center Decrypon Policy Rules

Intra-Data-Center Traffic Security Approach


The tradional legacy approach to securing east-west traffic between data center servers leaves
valuable assets exposed to risk, while the best pracce approach protects your valuable assets.

Data Center Best Pracce Security Policy Version Version 10.1 99 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

The Tradional Approach Risk The Best Pracce Approach

You don’t need to segment An aacker who Segment traffic between


traffic that doesn’t cross the compromises any data applicaon ers using
data center perimeter so center server can move ght allow rules to prevent
traffic between applicaon laterally to crical data unnecessary communicaon,
ers doesn’t need to center servers and repurpose reduce the aack surface, and
pass through the security them. Aackers inside the help prevent an aacker from
infrastructure. data center can move at moving laterally within the
will without fear of being data center. Log and monitor
discovered. allow list violaons.

The data center is safe inside Vulnerabilies remain open Install patches on data center
the trusted network, so it’s longer and present aack servers in a mely manner to
not urgent to patch data vectors to aackers. close down vulnerabilies.
center servers quickly. Creang allow list security
policy rules helps you
understand what is running
in your data center and
where unpatched services are
running.

Mix blocking and alerng A conglomeraon of The Palo Alto Networks


threat prevenon profiles individual tools leaves suite of coordinated security
from mulple vendors. security holes for aackers tools works together to
and may not work together plug security holes, prevent
well. aacks, and to idenfy
unknown malware aempng
to spread among data center
servers.

In addion:
• Create a unique service account for each funcon. For example, allow only specific service
accounts to replicate exchange mailboxes, and allow only specific service accounts on web
servers to query MySQL databases. Don’t use one service account for both funcons.
• Monitor service accounts.
• Don’t allow regular user accounts in the data center.

When you transion from port-based to applicaon-based rules, in the rulebase, place the
applicaon-based rule above the port-based rule it will replace. Reset the policy rule hit
counter for both rules. If traffic hits the port-based rule, its policy rule hit count increases.
Tune the applicaon-based rule unl no traffic hits the port-based rule for a period of me,
then remove the port-based rule.

Data Center Best Pracce Security Policy Version Version 10.1 100 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Create Intra-Data-Center Applicaon Allow Rules


Data center traffic oen consists of mul-er applicaon traffic that flows between different
server ers to provide services for applicaons such as SharePoint, WordPress, internal
proprietary applicaons, etc. The most common mul-er applicaon architecture consists of
web servers (presentaon er), applicaon servers (applicaon er), and database servers (data
er). Create a Data Center Segmentaon Strategy provides guidelines on how to place firewalls
between applicaon ers and how to segment a data center.
The way you treat traffic between data center servers depends on the traffic. For most applicaon
traffic, add threat prevenon profiles to the Security policy allow rules to inspect the traffic. For
example, always apply the best pracce Security Profiles to protect traffic between the web,
applicaon, and server ers of finance applicaons, engineering development applicaons,
and so on. The excepon to applying threat prevenon profiles is traffic for high-volume, low-
value applicaons such as mailbox replicaon and backup flows. You sll allow access to these
applicaons, but because a firewall has already inspected the traffic before replicaon, applying
threat prevenon profiles consumes firewall CPU cycles without providing extra value.

The WildFire security profile idenfies unknown malware aempng to spread among
data center servers to prevents the exfiltraon of data by discovering malware before it
can do damage. If you can’t use the WildFire global cloud, you can deploy a WildFire
private cloud or a WildFire hybrid cloud.

The example Security policy rules in this secon show how to allow traffic for mul-er data
center finance applicaons that require using the web server, applicaon server, and database
server ers to serve the applicaons. The example includes two proprietary internal applicaons
for which we created custom applicaons: Billing-App and Payment-App. Creang custom App-
IDs for these applicaons enables the firewall to idenfy them, control them, and apply Security
policy to them. Don’t allow unknown applicaons in the data center because you can’t idenfy
and apply security to them, and they may indicate an adversary in your data center. Every data
center applicaon should have an App-ID.

Allow applicaons only on their standard (applicaon-default) ports. In some cases,


business needs may require you to make an excepon and allow applicaons to use
non-standard ports between parcular clients and servers. In these cases, be aware of
the applicaon traffic running on non-standard ports, and ensure that you know every
instance of an applicaon running on a non-standard port. Applicaons that run on non-
standard ports for which you have not made an explicit (known) excepon may indicate
the presence of evasive malware.

Tag all sanconed applicaons with the predefined Sanconed tag. Panorama and
firewalls consider applicaons without the Sanconed tag as unsanconed applicaons.

Order the Data Center Security Policy Rulebase shows you how to order these rules with all of the
other rules we create for the other three data center traffic flows and the block rules so that no
rule shadows another rule.

Data Center Best Pracce Security Policy Version Version 10.1 101 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

To apply consistent security policy across mulple data centers, you can reuse templates
and template stacks so that the same policies apply to every data center. The templates
use variables to apply device-specific values such as IP addresses, FQDNs, etc., while
maintaining a global security policy and reducing the number of templates and template
stacks you need to manage.

Each of the following allow rules:


• Has the best pracce Security profile group aached, which consists of the best pracce
Security profiles. Using a Security profile group enables you to apply all of the best pracce
profiles to a rule at one me instead of specifying each profile individually. Security profile
groups make configuring protecon against malware, vulnerabilies, C2 traffic, and known and
unknown threats faster and easier.
• Logs traffic (at session end) so that you can track and analyze rule violaons and includes log
forwarding. Forward logs to log servers and when applicable, forward log emails to appropriate
administrators.
STEP 1 | Allow finance applicaon traffic between the web server er and the applicaon server er.
This rule restricts the traffic that can flow between the web server er and the applicaon
server er for the Finance department’s billing servers so that only traffic using legimate
applicaons can access the billing servers. (We also create a rule to restrict Finance user access
to the data center when we Create User-to-Data-Center Applicaon Allow Rules so that only
the right Finance users can access the data center.) The rule uses dynamic address groups
to specify the servers in each applicaon er—Web-Servers specifies the addresses of the
servers in the web server er and Billing-App-Servers specifies the addresses of the servers in
Finance’s billing applicaon server er.

To create this rule:


• Restrict the source of finance applicaon traffic to the web servers (Web-Servers) in the
Web-Server-Tier-DC zone.
• Restrict the desnaon for finance applicaon traffic to the billing servers (Billing-App-
Servers) in the App-Server-Tier-DC zone.
• Restrict the applicaons the web servers can use to access the billing applicaon servers
and only allow applicaons on their default ports. In this example, the applicaons include
two custom applicaons, Billing-App and Payment-App, for which you specify default
ports when you create the applicaons. The Finance Department uses these proprietary
applicaons for billing and payment services.
Create similar rules to control applicaons and traffic between the web server er and other
applicaon server ers.

Data Center Best Pracce Security Policy Version Version 10.1 102 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

STEP 2 | Allow finance applicaon traffic between the applicaons server er and the database server
er.
This rule restricts the traffic that can flow between the applicaon server er and the database
server er for the Finance department’s billing servers so that only traffic using legimate
applicaons can flow between the billing applicaon servers and the billing database servers.
The rule uses dynamic address groups to specify the servers in each applicaon er—Billing-
App-Servers specifies the addresses of the servers in the applicaon server er and DB2-
Servers specifies the addresses of the servers in Finance’s database server er.

To create this rule:


• Restrict the source of finance applicaon traffic to the billing applicaon servers (Billing-
App-Servers) in the App-Server-Tier-DC zone.
• Restrict the desnaon for finance applicaon traffic to the database servers (DB2-Servers)
in the DB-Server-Tier-DC zone.
• Restrict the applicaons the billing applicaon servers can use to access the database
servers and only allow applicaons on their default ports or their known non-default ports.
Create similar rules to control applicaons and traffic between the applicaon server er and
database server er for other applicaons.

Verify that only the applicaons you explicitly allowed in the security policy rules are running
by viewing the predefined Applicaons report (Monitor > Reports > Applicaon Reports >
Applicaons). If you see unexpected applicaons in the report, review the applicaon allow rules
and refine them so that they don’t allow the unexpected applicaons.

Create Intra-Data-Center Decrypon Policy Rules


Why decrypt traffic inside the data center? Aer all, there are no users and the data center is a
safe environment deep inside the secure network. But nothing could be farther from the truth.
The data center is a perfect place for aackers to hide precisely because many people think the
data center is safe and don’t look there. But the same basic tenet that’s true in the rest of the
network holds true in the data center: you can’t protect yourself against what you can’t see.
Decrypt encrypted data center traffic so that the firewall can inspect traffic, control access, make
threats visible, and protect your valuable assets.
Some data center traffic is unencrypted (cleartext). Don’t enable decrypon on cleartext flows
because there is nothing to decrypt.
In Create Intra-Data-Center Applicaon Allow Rules, we created Security policy rules that allow
servers involved with Finance Department applicaons that are in different applicaon ers to
communicate with each other. Here we create analogous Decrypon policy rules to decrypt the
traffic that those rules allow.
For each rule, configure decrypon logging and log forwarding. Log as much decrypon traffic as
your firewall resources permit.

Data Center Best Pracce Security Policy Version Version 10.1 103 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

STEP 1 | Decrypt finance applicaon traffic between the web server er and the applicaon server
er.
This rule decrypts the traffic flowing between the web server er and the applicaon server
er for the Finance department’s billing servers so that the firewall can see the traffic and
protect the servers in each er against potenal threats.

To create this rule:


• Specify the same source and desnaon as in the analogous Security policy rule. In this
example, the source is the Web-Servers dynamic address group in the Web-Server-Tier-DC
zone, and the desnaon is the Billing-App-Servers in the App-Server-Tier-DC zone.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Forward
Proxy. Apply the data center best pracce Decrypon Profile to apply SSL Forward Proxy
and SSL Protocol Sengs to the traffic.

STEP 2 | Decrypt finance applicaon traffic between the applicaon server er and the database
server er.
This rule decrypts the traffic flowing between the applicaon server er and the database
server er for the Finance department’s billing servers so that the firewall can see the traffic
and protect the servers in each er against potenal threats.

To create this rule:


• Specify the same source and desnaon as in the analogous Security policy rule. In this
example, the source is the Billing-App-Servers dynamic address group in the App-Server-
Tier-DC zone, and the desnaon is the DB2-Servers in the DB-Server-Tier-DC zone.
• On the Opons tab, set the Acon to Decrypt and the decrypon Type to SSL Forward
Proxy. Apply the data center best pracce Decrypon Profile to apply SSL Forward Proxy
and SSL Protocol Sengs to the traffic.

Data Center Best Pracce Security Policy Version Version 10.1 104 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Order the Data Center Security Policy Rulebase


This topic provides a snapshot of the example Security policy rulebase that shows the order of the
rules for all four data center traffic flows. The preceding secons discuss each Security policy rule
in detail (as well as the Decrypon policy rules, and where required, the Authencaon policy and
DoS Protecon policy rules).
The order of the Security policy rules is crical. No rule should shadow another rule. For example,
block rules should not block traffic that you want to allow, so you must place allow rules before
the rule that would block the traffic goes into effect. In addion, an allow rule should not allow
traffic that you want to block. By creang very specific allow rules, you ghtly control the allowed
applicaons and who can and cannot use them.
Rules 1-7: The first two rules block the QUIC applicaon to prevent it from blocking traffic
or prevenng decrypon. The next five rules allow DNS access for users and allow specific
applicaon and server access for specific user groups. These are the rules configured in Create
User-to-Data-Center Applicaon Allow Rules.

Figure 1: Data Center Rules 1-7

Only the specified users can use only the specified applicaons on their default ports to access
only the specified data center desnaon servers (addresses). Security profiles protect all of these
allow rules against threats. These rules precede block rules that discover unknown users and
applicaons on the network because these rules are very specific and they prevent sanconed
users and applicaons from matching more general rules lower in the rulebase.
Rules 8-9: While the preceding rules allow sanconed applicaons, the next two rules, created in
Create Data Center Traffic Block Rules, discover and block unexpected applicaons from users on
standard ports and block all applicaons on non-standard ports. (Your deployment may have more
user zones than shown in the example.)

Data Center Best Pracce Security Policy Version Version 10.1 105 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Figure 2: Data Center Rules 8-9

Traffic from non-user zones doesn’t match these rules. Place these rules above the applicaon
blocking rules (rules 18 and 19) or those rules will shadow these rules. (Traffic that matches these
two rules may also match the more general applicaon blocking rules. If the applicaon blocking
rules come first and match traffic that also matches these rules, that traffic won’t match these
rules and won’t be logged separately, so the rules won’t do their intended job of differenang
blocking that is the result of employee user acvity from blocking that is the result of acvity from
non-user zones.)
Rules 10-16: The next seven rules allow traffic between the data center and the internet and
within the data center (created in Create Internet-to-Data-Center Applicaon Allow Rules, Create
Data-Center-to-Internet Applicaon Allow Rules, and Create Intra-Data-Center Applicaon Allow
Rules.) Security profiles protect all of these allow rules against threats.

Figure 3: Data Center Rules 10-16

Rules 17-20: The last four rules, configured in Create Data Center Traffic Block Rules, block
applicaons that you know you don’t want in your data center and unexpected applicaons, and
discover unknown users on your network.

Rule 17 blocks applicaons you never want in your data center. This rule comes aer the
applicaon allow rules to enable access for excepons. For example, you may sancon one or

Data Center Best Pracce Security Policy Version Version 10.1 106 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

two file sharing applicaons in applicaon allow rules that precede this block rule, and then
the applicaon filter in this rule blocks the rest of that applicaon type to prevent the use of
unsanconed file sharing applicaons. If there are sets of applicaons or individual applicaons
that you never want on your network and for which there are no excepons, for example,
BitTorrent, you can create a specific block rule to block just those applicaons and place it at the
top of the rulebase, above the applicaon allow rules. However, if you do this, you must be certain
that none of the blocked applicaons have legimate business uses because users will not be able
to access them.
Rules 18 and 19 are analogous to rules 8 and 9, which discover unexpected applicaons from
users (the traffic those rules apply to comes only from user zones). Rules 18 and 19 discover
unexpected applicaons from all other zones. Having separate rules enables you to log blocking
rule matches with greater granularity.
Rule 20 discovers unknown users so that you can log those aempted accesses separately for
easier invesgaon.
As with all Security Policy rulebases, the final two rules will be the Palo Alto Networks default
rules for intrazone traffic (allow) and interzone traffic (deny).

Data Center Best Pracce Security Policy Version Version 10.1 107 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Log and Monitor Data Center Traffic


The firewall’s logging and monitoring tools reveal applicaons, users, and traffic paerns on your
network, including applicaons and users you may not have known were there. Logging and
monitoring provides useful informaon at all stages of the transion to and maintenance of a data
center best pracce security policy because it also reveals unknown users (not idenfied by User-
ID), unknown applicaons, and traffic on unexpected ports, all of which indicate that a Security
policy rule has not be correctly or ghtly constructed. Logging and monitoring informaon help
you determine which applicaons to allow and which users to allow access to which applicaons
and devices, and also helps you invesgate potenal security issues.
When you assess your data center, you capture baseline measurements. Periodically compare
those baseline measurements with current measurements to evaluate progress, idenfy changes,
and find areas for improvement as you implement your data center best pracce Security policy.

If you use Panorama to manage firewalls, you can monitor firewall health to compare
devices to their baseline performance and to each other to idenfy deviaons from normal
behavior.

Configure log forwarding from firewalls to Panorama or to external services such as an SNMP Trap
server or a syslog server to centralize the logs from mulple firewalls for more convenient viewing
and analysis (a firewall can only display local logs and reports, not logs and reports from other
firewalls). When you configure log forwarding, configure sending noficaons to verify that the
log desnaons you configure are receiving the firewall logs.
Best pracces for data center logging and monitoring include:
• What Data Center Traffic to Log and Monitor
• Monitor Data Center Block Rules and Tune the Rulebase
• Log Data Center Traffic That Matches No Interzone Rules
• Log Intra Data Center Traffic That Matches the Intrazone Allow Rule

What Data Center Traffic to Log and Monitor


The Palo Alto Networks next-generaon firewall creates some logs by default, while you need to
configure logging for other traffic. The best pracce is to log all data center traffic and monitor the
logs for unexpected applicaons, users, traffic, and behaviors.
By default, the firewall logs traffic that matches explicitly configured Security policy rules and
does not log traffic that matches the predefined intrazone-default (allows traffic with a source and
desnaon in the same zone) and interzone-default (the last rule in the rulebase, which denies
traffic that matches no preceding rules) rules at the boom of the rulebase.
When you create a Security policy rule, by default the firewall logs the traffic at the end of the
session:

Data Center Best Pracce Security Policy Version Version 10.1 108 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

However, the firewall does not forward logs by default and does not apply Security profiles by
default. The preceding example shows the best pracce of forwarding logs to the appropriate log
servers and administrators and applying best pracce Security profiles.
The best pracce for most traffic is to Log at Session End because applicaons oen change
throughout the lifespan of a session. For example, the inial App-ID for a session may be web-
browsing, but aer the firewall processes a few packets, the firewall may find a more specific App-
ID for the applicaon and change the App-ID. There are several use cases for logging traffic at
the start of a session, including DNS sinkholing, long-lived tunnel sessions, and when you need
informaon from the start of the session for troubleshoong.

Logging the traffic records informaon about traffic that a rule allows and traffic that
a rule denies or drops (rule violaons), so the firewall provides valuable informaon
regardless of how the it treats the traffic. Rule violaons highlight potenal aacks or
allow rules that need to be adjusted to allow a legimate business applicaon.

When you examine blocked traffic in logs, differenate between traffic that the firewall blocked
as a protecve event before any systems have been compromised, such as blocking an applicaon
that isn’t allowed, and traffic that the firewall blocked as a post-compromise event, for example,
an aempt by malware that is already on a data center server to contact an external server to
download more malware or exfiltrate data.
The firewall provides a wealth of monitoring tools, logs, and log reports with which to analyze your
network:
• Monitor > Logs provides traffic, threat, User-ID, and many other log types, including Unified
logs, which show mulple log types on one screen so you don’t have to look at different types
of logs separately. When a magnifying glass icon is part of the summary, you can click it to drill
down into the log entry.
• Monitor > PDF Reports provides predefined reports that you can view and the ability to create
report groups composed of predefined and custom reports. For example, you can review traffic
acvity or take baseline measurements to understand the bandwidth usage and traffic flow in
each data center segment by zone or interface.
• Monitor > Manage Custom Reports provides the ability to create customized reports so that
you can view informaon about block rules, allow rules, or any other subject of interest.
• Monitor > Packet Capture enables you to take packet captures of traffic that traverses the
firewall’s management interface and network interfaces.
• The Applicaon Command Center ( ACC) provides widgets that display an interacve, graphical
summary of the applicaons, users, URLs, threats, and content traversing the network. For
example, you can review and evaluate the applicaons on the network ( ACC > Network
Acvity > Applicaon Usage > Threats) to see if there are any changes in the applicaon or if

Data Center Best Pracce Security Policy Version Version 10.1 109 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

the applicaon exhibits threat behaviors. If you see unexpected applicaons in the list, evaluate
how to handle those applicaons.
Another good way to use ACC informaon is to help idenfy compromised user accounts and
host systems. Analyze threats along with the usernames associated with the threats using
the ACC > Network Acvity > User Acvity > Threats widget and then use the threat logs to
isolate the exact issue.
• The Dashboard ( Dashboard) provides widgets that display general firewall informaon and up
to 10 of the most recent entries in the threat, configuraon, and system logs.
• Use Panorama to monitor firewall health and baseline new devices, to compare performance
metrics, and to track firewall performance aer an event such as a commit, a soware upgrade,
content updates, rule changes, the addion of new applicaons, etc. If performance deviates
from a device’s baseline, you can view and troubleshoot manually or automacally open a cket
for invesgaon.
• On Panorama or on an individual firewall, use the policy rule hit counter to analyze changes to
the rulebase. For example, when you add a new applicaon, before you allow that applicaon’s
traffic on the network, add the allow rule to the rulebase. If traffic hits the rule and increments
the counter, it indicates traffic that matches the rule may already be on the network even
though you haven’t acvated the applicaon, or that you need to tune the rule. Another
example is replacing port-based rules with applicaon-based rules by placing the applicaon-
based rule before the port-based rule and nong if any traffic hits the port-based rule. If traffic
hits the port-based rule, then you need to tune the applicaon-based rule to catch that traffic.
In conjuncon with the policy rule hit counter, check the ACC > Threat Acvity > Applicaons
Using Non Standard Ports and the ACC > Threat Acvity > Rules Allowing Apps On Non
Standard Ports widgets to see if traffic on non-standard ports caused the unexpected rule hits.

The key to using the policy rule hit counter is to reset the counter when you make a
change, such as introducing a new applicaon or changing a rule’s meaning. Reseng
the hit counter ensures that you see the result of the change, not results that include
the change and events that happened before the change.

Monitor Data Center Block Rules and Tune the Rulebase


Developing a best pracce security policy is an iterave process. As soon as you Create Data
Center Traffic Block Rules, start monitoring traffic that matches the block rules designed to
idenfy policy gaps, unexpected behaviors, and potenal aacks. Tune your applicaon allow
rules to account for traffic that matches the block rules but should be allowed and invesgate
traffic that may indicate an aack.
Reports on blocked traffic contain valuable informaon you can use to invesgate potenal issues.
Keep the block rules in the rulebase to protect your valuable data center assets and provide that
informaon when traffic matches a block rule.

Follow content update best pracces to keep your firewall protecon up-to-date.
Maintain the Data Center Best Pracce Rulebase includes specific best pracces for
data center firewalls.

Data Center Best Pracce Security Policy Version Version 10.1 110 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

STEP 1 | Create custom reports to monitor traffic that matches the block rules designed to idenfy
policy gaps and potenal aacks.
1. Select Monitor > Manage Custom Reports.
2. Add a report and give it a Name that describes the report’s purpose, in this example DC
Best Pracce Policy Tuning.
3. Set the Database to Traffic Summary. This also changes the Available Columns opons.
4. From Available Columns, add Source Zone, Desnaon Zone, Sessions, Bytes, Applicaon,
Risk of App, Rule, and Threats to the Selected Columns list. If there are other types of
informaon you want to monitor, select those as well.
5. Select the Scheduled box.
6. Set the desired Time Frame, Sort By, and Group By values. In this example we set the Time
Frame to Last 7 Days, the Sort By to Apps, and the Group By to App Sub Category.
7. Define the query to match traffic hing the rules designed to find policy gaps and potenal
aacks. You can create a single report for traffic that matches any of the rules using the or
operator, or create individual reports to monitor each rule. In the Query Builder, specify the
name of each rule you want to include in the report. This example uses the six blocking rules
and uses the Or operator to include informaon about traffic that matches any of the rules:
• (rule eq ‘Discover-Unknown-Users’)
• (rule eq ‘Block-Bad-Apps’)
• (rule eq ‘Unexpected-App-from-User-Zone’)
• (rule eq ‘Unexpected-App-from-Any-Zone’)
• (rule eq ‘Unexpected-User-App-Any-Port’)
• (rule eq ‘Unexpected-App-Any-Port’)

STEP 2 | Review the report (or reports) regularly to make sure you understand why traffic matches
each block rule and either update policy to include legimate applicaons and users, or use
the informaon to assess the risk of traffic that matches the rules.

Data Center Best Pracce Security Policy Version Version 10.1 111 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Log Intra Data Center Traffic That Matches the Intrazone Allow
Rule
By default, all intrazone traffic (source and desnaon in the same zone) is allowed. Aer the
firewall evaluates Security policy, it either allows traffic controlled by applicaon allow list rules,
denies traffic controlled by block rules, or if intrazone traffic matches no rules, the firewall allows it
by default. (The firewall blocks interzone traffic by default.) Because of the valuable nature of data
center assets, the best pracce is to monitor all traffic inside the data center between data center
servers, including traffic allowed by the intrazone default allow rule.
To gain visibility into this traffic, enable logging on the intrazone-default rule when it applies
to traffic within zones inside the data center. Logging this traffic gives you the opportunity to
examine access that you have not explicitly allowed and which you may want to either explicitly
allow by modifying an allow rule or explicitly block.
In Define the Inial Intra-Data-Center Traffic Security Policy, we used three example zones inside
the data center: Web-Server-Tier-DC, App-Server-Tier-DC, and DB-Server-Tier-DC. In this
example, we create a custom report to gather log informaon about data center intrazone traffic
in these three internal data center zones.
STEP 1 | Select the intrazone-default row in the rulebase and click Override to enable eding the rule.

STEP 2 | Select the intrazone-default rule name to edit the rule.

STEP 3 | On the Acons tab, select Log at Session End and click OK.

STEP 4 | Create a custom report to monitor traffic that hits this rule for the internal data center zones.
1. Select Monitor > Manage Custom Reports.
2. Add a report and give it a descripve Name. In this example, the name is Log Intrazone-
Default Rule-DC.
3. Set the Database to Traffic Summary.
4. From Available Columns, add Source Zone, Desnaon Zone, Sessions, Bytes, Applicaon,
Risk of App, Rule, and Threats to the Selected Columns list. If there are other types of
informaon you want to monitor, select those as well.
5. Select the Scheduled box.
6. Set the desired Time Frame, Sort By, and Group By values. In this example, the selected
values are Threats and App Category, respecvely.
7. Define the query to match traffic that matches the intrazone-default rule for the data center
zones:

(rule eq intrazone-default) and ((zone eq Web-Server-Tier-DC) or


(zone eq App-Server-Tier-DC) or (zone eq DB-Server-Tier-DC))

The query filters for traffic that matches the intrazone default rule and also matches any of
the three internal data center zones that we defined. Because the default Selected Columns
include zones, the report shows the zone for each session. In a real-world data center, you

Data Center Best Pracce Security Policy Version Version 10.1 112 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

would probably have more zones and you would add each zone to the query. The resulng
custom report sengs look like this:

8. Commit the changes.

Log Data Center Traffic That Matches No Interzone Rules


Traffic that doesn’t match any of the Security policy rules you configure matches the predefined
interzone-default block rule at the boom of the rulebase and is denied. To gain visibility into
traffic that doesn’t match a rule you explicitly configured, enable logging on the interzone-default
rule. Logging this traffic gives you the opportunity to examine access aempts that you have not
explicitly allowed, which may idenfy aack aempts or traffic for which you want to modify an
allow rule.
STEP 1 | Select the interzone-default row in the rulebase and click Override to enable eding the rule.

STEP 2 | Select the interzone-default rule name to edit the rule.

STEP 3 | On the Acons tab, select Log at Session End and click OK.

Data Center Best Pracce Security Policy Version Version 10.1 113 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

STEP 4 | Create a custom report to monitor traffic that hits this rule.
1. Select Monitor > Manage Custom Reports.
2. Add a report and give it a descripve Name. In this example, the name is Log Interzone-
Default Rule.
3. Set the Database to Traffic Summary.
4. From Available Columns, add Source Zone, Desnaon Zone, Sessions, Bytes, Applicaon,
Risk of App, Rule, and Threat to the Selected Columns list. If there are other types of
informaon you want to monitor, select those as well.
5. Select the Scheduled box.
6. Set the desired Time Frame, Sort By, and Group By values. In this example, the selected
values are Last 7 Days, Threats and App Category, respecvely.
7. Define the query to match traffic that matches the interzone-default rule:

(rule eq interzone-default)

The resulng custom report sengs look like this:

8. Commit the changes.

Data Center Best Pracce Security Policy Version Version 10.1 114 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Maintain the Data Center Best Pracce Rulebase


Applicaons constantly evolve, so your applicaon allow list needs to evolve with them. Because
the best pracce rules leverage policy objects to simplify administraon, adding support for a
new applicaon or removing an applicaon from your allow list typically means modifying the
corresponding applicaon group or applicaon filter accordingly.
Palo Alto Networks sends content updates that you should download automacally and schedule
for installaon on firewalls as soon as possible. Most content updates contain updates to threat
content (anvirus, vulnerabilies, an-spyware, etc.) and may contain modified App-IDs. On the
third Tuesday of each month, the content update also contains new App-IDs. You can set separate
thresholds to delay installing regular content updates and to delay installing the once-a-month
update that contains new App-IDs for a specified period of me aer the download. Delaying
installaon enables you to install content updates that don’t include new App-IDs as quickly as
possible to get the latest threat signatures, while also providing more me to examine new App-
IDs before installing them.
The content updates on the third Tuesday of each month that contain new App-IDs may cause
changes in Security policy enforcement. Before you install new or modified App-IDs, review the
policy impact, stage updates to test impact, and modify exisng Security policy rules if necessary.
The most efficient way to control downloading and installing content updates on firewalls is
loading them on and pushing them from Panorama if you use Panorama.
Follow the general content update best pracces, but keep in mind that data center availability is
usually crical, so you may not choose to roll out content updates as fast in the data center as you
would on internet-facing firewalls:
• Quickly test content updates in a safe area of the network before you install them in the data
center.
• For content updates that don’t contain new App-IDs, set the installaon threshold to no more
than eight hours aer the automac download and conduct tesng within that period.
• For content updates that contain new App-IDs, set the installaon threshold to no more than
eight days aer the automac download and conduct tesng within that period.
• Configure Log Forwarding for all content updates.
STEP 1 | Before installing a new content update, review new and modified App-IDs to determine if
there is policy impact.

STEP 2 | If necessary, modify exisng Security policy rules to accommodate the App-ID changes.
You can disable selected App-IDs if some App-IDs require more tesng and install the rest
of the new App-IDs. Finish tesng any necessary policy revisions before the next monthly
content release with the new App-IDs arrives (third Tuesday of each month) to avoid overlap.

Over me, the list of applicaons used in the data center usually stabilizes, so fewer
and fewer new App-IDs are relevant. (Most new App-IDs pertain to internet-facing
applicaons.) This reduces the risk of new App-IDs creang an issue in the data center
and may enable you to install content updates with new App-IDs faster.

STEP 3 | Prepare policy updates to account for App-ID changes included in a content release or to add
new sanconed applicaons to or remove applicaons from your allow rules.

Data Center Best Pracce Security Policy Version Version 10.1 115 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Other ways to maintain the best pracce rulebase include:


• Use Palo Alto Networks Assessment and Review Tools to idenfy gaps in security coverage.
• User feedback about applicaons they can no longer access may idenfy gaps in the rulebase
or risky applicaons that were in use on your network before posive enforcement prevented
their use.
• Compare the asset inventory list you created when you assessed you data center to the assets
themselves and ensure that those assets are protected appropriately.
• Use Palo Alto Networks logging and monitoring tools such as the Applicaon Command Center
(ACC) to find and invesgate unexpected acvity, which may indicate a misconfigured or
missing rule. Run reports periodically to check that the level of security you want to apply is
applied.

If you use Panorama to manage firewalls, you can monitor firewall health to compare
devices to their baseline performance and to each other to idenfy deviaons from
normal behavior.

Data Center Best Pracce Security Policy Version Version 10.1 116 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Use Palo Alto Networks Assessment and Review Tools


The Customer Success Team at Palo Alto Networks has developed a prevenon architecture with
tools and resources to help you review and assess the security risks of your network and how well
you have used the capabilies of the firewall and other tools to secure your network. Contact your
Palo Alto Networks representave to schedule assessments and reviews (a Palo Alto Networks
sales engineer conducts the reviews to provide experse in assessing the security state of your
network). As of this publicaon, the available Security Risk prevenon tools include:
• Prevenon Posture Assessment (PPA)—The PPA is a set of quesonnaires that help uncover
security risk prevenon gaps across all areas of network and security architecture. The PPA not
only helps to idenfy all security risks, it also provides detailed suggesons on how to prevent
the risks and close the gaps. The assessment, guided by an experienced Palo Alto Networks
sales engineer, helps determine the areas of greatest risk where you should focus prevenon
acvies. You can run the PPA on firewalls and on Panorama.
• Best Pracce Assessment (BPA) Tool—The BPA for next-generaon firewalls and Panorama
evaluates a device’s configuraon by measuring the adopon of capabilies, validang whether
the policies adhere to best pracces, and providing recommendaons and instrucons for how
to remediate failed best pracce checks.
The Security Policy Adopon Heatmap component filters the informaon by device groups,
serial numbers, zones, areas of architecture, and other categories. The results include trending
data, which shows the rate of security improvement as you adopt new capabilies, fix gaps, and
progress toward a Zero-Trust network.
The BPA component performs more than 200 security checks on a firewall or Panorama
configuraon and provides a pass/fail score for each check. Each check is a best pracce
idenfied by Palo Alto Networks security experts. If a check returns a failing score, the tool
provides the jusficaon for the failing score and how to fix the issue.
Palo Alto Networks connues to develop new tools and refine exisng tools. Contact your Palo
Alto Networks representave to find out what the most current tools can do to increase your data
center network security.

Data Center Best Pracce Security Policy Version Version 10.1 117 ©2021 Palo Alto Networks, Inc.
Data Center Best Pracce Security Policy

Data Center Best Pracce Security Policy Version Version 10.1 118 ©2021 Palo Alto Networks, Inc.

You might also like