PCI DSS 1.4.2: Inbound traffic from untrusted networks to trusted networks is restricted
PCI DSS v4.0.1 control 1.4.2: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 1.4.
Requirement 1: Install and Maintain Network Security Controls › Section 1.4
Inbound traffic from untrusted networks to trusted networks is restricted to:
- Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.
- Stateful responses to communications initiated by system components in a trusted network.
- All other traffic is denied.
Summary
From an untrusted network, only the systems meant to be reachable are reachable, plus the replies to conversations your side started. Everything else is denied.
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.4.2 | Examine vendor documentation and configurations of NSCs to verify that inbound traffic from untrusted networks to trusted networks is restricted in accordance with all elements specified in this requirement. |
The second bullet is the one that decides your architecture: stateful responses to communications initiated by system components in a trusted network. Permitting return traffic requires the device to know a conversation was started from inside, which is what makes a stateful control necessary rather than optional here. A stateless access list that allows high ports inbound so replies get through is the classic way this fails, because it permits far more than responses. The first bullet is the DMZ principle stated plainly: inbound reaches only components authorized to provide publicly accessible services, so a database reachable from the internet fails regardless of how well it is authenticated. The third closes it: all other traffic denied, which pairs with the explicit-deny expectation in 1.3.1.
What to prepare
- The list of components intended to be publicly reachable, and what each provides.
- NSC configurations showing statefulness, not just permit rules.
- Vendor documentation for the devices relied on, which the procedure examines.
- The deny rule that terminates the inbound ruleset.
How to implement it
1. Rely on state, not on port ranges. Any rule permitting a wide inbound port range so that replies work is a sign the control is stateless underneath.
2. Justify each publicly reachable component. The first bullet is about authorisation, so a component exposed because it always has been is not covered by it.
3. Check the cloud equivalents. Security groups are stateful and network ACLs are not, and mixing them is how an environment ends up with stateless rules nobody intended.
4. Terminate with an explicit deny. A ruleset that denies by omission is harder to evidence than one that ends in a rule you can point at.
Where this commonly fails
- Wide inbound port ranges opened to make return traffic work.
- Stateless network ACLs relied on where statefulness was assumed.
- Internal services reachable from the internet because a rule was broader than intended.
- Publicly reachable components that nobody authorised, discovered by an external scan rather than by review.
Related controls
Others in section 1.4:
| Control | What it requires |
|---|---|
| 1.4.1 | NSCs are implemented between trusted and untrusted networks |
| 1.4.3 | Anti-spoofing measures are implemented to detect and block forged source IP addresses… |
| 1.4.4 | System components that store cardholder data are not directly accessible from untrusted networks |
| 1.4.5 | The disclosure of internal IP addresses and routing information is limited to only authorized… |
← 1.4.1 · All controls · 1.4.3 →
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.