WithPCI Logo
WithPCI.com

1.3.1 Inbound traffic to the CDE is restricted only traffic that is necessary and all other traffic is specifically denied.

Original requirement from PCI DSS v4.0.1

Defined Approach Requirements

1.3.1 Inbound traffic to the CDE is restricted as follows:

  • To only traffic that is necessary.
  • All other traffic is specifically denied.

Customized Approach Objective

Unauthorized traffic cannot enter the CDE.

Defined Approach Testing Procedures

1.3.1.a Examine configuration standards for NSCs to verify that they define restricting inbound traffic to the CDE is in accordance with all elements specified in this requirement.

1.3.1.b Examine configurations of NSCs to verify that inbound traffic to the CDE is restricted in accordance with all elements specified in this requirement.

Purpose

This requirement aims to prevent malicious individuals from accessing the entity's network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner.

Good Practice

All traffic inbound to the CDE, regardless of where it originates, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to ensure traffic is restricted to only authorized communications-for example, by restricting source/destination addresses and ports, and blocking of content.

Implementing a rule that denies all inbound and outbound traffic that is not specifically needed-for example, by using an explicit "deny all" or implicit deny after allow statement-helps to prevent inadvertent holes that would allow unintended and potentially harmful traffic.

purpose

Prevent unauthorized ingress to the CDE.

whats required for compliance

  • NSC rules restrict inbound CDE traffic to only what’s needed.
  • Explicit deny for all other traffic.

compliance strategies

  • Default-deny firewall rules
  • Allow-listing
  • Periodic rules review

typical policies procedures

  • CDE Access Control Policy
  • Threat Intelligence Integration

common pitfalls failures

  • Missing explicit deny at end of ruleset
  • Unapproved cloud API endpoints

type

Technical Control

difficulty

High

key risks

  • Direct exploitation of CDE

product vendor recommendations

  • Use next-gen firewalls (Palo Alto, Fortinet)

Eligible SAQ

  • SAQ-A-EP
  • SAQ-B-IP
  • SAQ-C
  • SAQ-C-VT
  • SAQ-D MERCHANT
  • SAQ-D SERVICE PROVIDER

Your perspective on this PCI DSS requirement matters! Share your implementation experiences, challenges, or questions below. Your insights help other organizations improve their compliance journey and build a stronger security community.Comment Policy