: Define the Initial Intra-Data-Center Traffic Security Policy
Focus
Focus

Define the Initial Intra-Data-Center Traffic Security Policy

Table of Contents
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.