Define the Initial Intra-Data-Center Traffic Security Policy
Table of Contents
10.0 (EoL)
Expand all | Collapse all
-
- What Is a Data Center Best Practice Security Policy?
- Why Do I Need a Data Center Best Practice Security Policy?
- Data Center Best Practice Methodology
- How Do I Deploy a Data Center Best Practice Security Policy?
- How to Assess Your Data Center
-
- Create the Data Center Best Practice Antivirus Profile
- Create the Data Center Best Practice Anti-Spyware Profile
- Create the Data Center Best Practice Vulnerability Protection Profile
- Create the Data Center Best Practice File Blocking Profile
- Create the Data Center Best Practice WildFire Analysis Profile
- Use Cortex XDR Agent to Protect Data Center Endpoints
- Create Data Center Traffic Block Rules
- Order the Data Center Security Policy Rulebase
- Maintain the Data Center Best Practice Rulebase
- Use Palo Alto Networks Assessment and Review Tools
End-of-Life (EoL)
Define the Initial Intra-Data-Center Traffic Security Policy
Define the traffic that can flow between data center
server tiers to provide application services.
Intra data center traffic flows between data center
servers and application tiers. 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 attacker compromises
a data center server and the traffic between application tiers doesn’t
go through firewalls, the attacker can move laterally through the
data center to critical servers and download more malware, repurpose
servers, and exfiltrate data using legitimate applications 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 application
allow rules and to inspect the traffic with next-generation firewalls
placed between application tiers.
In addition, allow no unknown applications in the data center.
Unknown applications may indicate that an adversary has gained access
to your data center. Create custom applications for your proprietary internal
applications so that you can identify them with App-ID and apply security to that traffic.
If you don’t create custom applications for your proprietary applications,
the firewall sees them as unknown-tcp or unknown-udp traffic. The
issue is that the firewall treats the proprietary applications the
same way it treats other unknown applications, and you should block
unknown applications because they may be an attacker’s tools. If you
allow unknown applications in your data center, you could be handing
over the keys to your asset kingdom to an attacker.
For unknown commercial applications, you can submit a request to Palo Alto Networks
to create an App-ID.
If you have existing Application Override policies that you created
solely to define custom session timeouts for a set a of ports, convert
the existing Application Override policies to application-based
policies by configuring service-based session timeouts to maintain
the custom timeout for each application and then migrating the rule
the an application-based rule. Application Override policies are
port-based. When you use Application Override policies to maintain
custom session timeouts for a set of ports, you lose application
visibility into those flows, so you neither know nor control which
applications use the ports. Service-based session timeouts achieve
custom timeouts while also maintaining application visibility.