Define the Initial Intra-Data-Center Traffic Security Policy

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