: Intra-Data-Center Traffic Security Approach
Focus
Focus

Intra-Data-Center Traffic Security Approach

Table of Contents

Intra-Data-Center Traffic Security Approach

Learn the risks of the traditional approach to securing traffic flowing between data center servers (east-west traffic) and how the best practice approach mitigates those risks.
The traditional legacy approach to securing east-west traffic between data center servers leaves valuable assets exposed to risk, while the best practice approach protects your valuable assets.
The Traditional Approach
Risk
The Best Practice Approach
You don’t need to segment traffic that doesn’t cross the data center perimeter so traffic between application tiers doesn’t need to pass through the security infrastructure.
An attacker who compromises any data center server can move laterally to critical data center servers and repurpose them. Attackers inside the data center can move at will without fear of being discovered.
Segment traffic between application tiers using tight allow rules to prevent unnecessary communication, reduce the attack surface, and help prevent an attacker from moving laterally within the data center. Log and monitor allow list violations.
The data center is safe inside the trusted network, so it’s not urgent to patch data center servers quickly.
Vulnerabilities remain open longer and present attack vectors to attackers.
Install patches on data center servers in a timely manner to close down vulnerabilities. Creating allow list security policy rules helps you understand what is running in your data center and where unpatched services are running.
Mix blocking and alerting threat prevention profiles from multiple vendors.
A conglomeration of individual tools leaves security holes for attackers and may not work together well.
The Palo Alto Networks suite of coordinated security tools works together to plug security holes, prevent attacks, and to identify unknown malware attempting to spread among data center servers.
In addition:
  • Create a unique service account for each function. 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 functions.
  • Monitor service accounts.
  • Don’t allow regular user accounts in the data center.
When you transition from port-based to application-based rules, in the rulebase, place the application-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 application-based rule until no traffic hits the port-based rule for a period of time, then remove the port-based rule.

Recommended For You