PCI DSS 1.3.1: Inbound traffic to the CDE is restricted
PCI DSS v4.0.1 control 1.3.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 1.3.
Requirement 1: Install and Maintain Network Security Controls › Section 1.3
Inbound traffic to the CDE is restricted as follows:
- To only traffic that is necessary.
- All other traffic is specifically denied.
Summary
Only necessary traffic reaches the cardholder data environment, and everything else is denied by an explicit rule rather than by omission.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 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. |
The heart of Requirement 1: most of the rest exists to prove this restriction is real, documented and reviewed. Two words carry it. Necessary means each allowance has a business justification, which is what 1.2.1 asks you to record. Specifically denied means a default-deny rule you can point at, not an absence of matching rules; a ruleset that happens to have nothing permitting a flow is not the same as one that denies it, because the next change can silently create the flow. 1.3.1.a examines the configuration standards and 1.3.1.b examines the actual NSC configurations, so this is one of the controls where the document and the device are compared directly.
What to prepare
- Current network security control rulesets, exported from the devices rather than transcribed.
- The business justification for each inbound allowance.
- A network diagram and data-flow diagram that agree with the rules, per 1.2.4.
- Evidence of the explicit deny at the end of each ruleset.
How to implement it
1. Write the deny rule even where the platform defaults to it. Cloud security groups deny by default, which satisfies the intent, but the evidence is then a property of the platform rather than of your configuration. State it in the standard so the assessor is examining a decision.
2. Justify allowances by flow, not by port. "443 inbound" describes a rule; "the payment page reached by customers over HTTPS" describes a flow, and it is the second that lets you tell later whether the rule is still necessary.
3. Reconcile the ruleset with the diagram, both directions. Rules with no flow on the diagram and flows with no rule are both findings, and the second usually means the diagram is out of date rather than that the traffic does not happen.
4. Treat management and monitoring paths as inbound traffic. Backup agents, monitoring collectors and jump hosts reach into the CDE and are frequently omitted because they are ours rather than the internet’s.
Where this commonly fails
- Relying on an implicit deny, so nothing in the configuration expresses the intent.
- Rules accumulated for troubleshooting and never removed, with no justification recorded to test them against.
- A diagram that shows the designed flows and a ruleset that shows the real ones, differing by several years.
- Broad allowances to an internal range treated as trusted, when the requirement is about what is necessary rather than about where it comes from.
Related controls
Others in section 1.3:
| Control | What it requires |
|---|---|
| 1.3.2 | Outbound traffic from the CDE is restricted… |
| 1.3.3 | NSCs are installed between all wireless networks and the CDE… |
← 1.2.8 · All controls · 1.3.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.