PCI DSS 1.4.1: NSCs are implemented between trusted and untrusted networks
PCI DSS v4.0.1 control 1.4.1: the requirement in full, the 2 testing procedures 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
NSCs are implemented between trusted and untrusted networks.
Summary
Something enforces the boundary between your trusted network and everything untrusted.
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.1.a | Examine configuration standards and network diagrams to verify that NSCs are defined between trusted and untrusted networks. |
| 1.4.1.b | Examine network configurations to verify that NSCs are in place between trusted and untrusted networks, in accordance with the documented configuration standards and network diagrams. |
The structural requirement behind 1.3.1: that control restricts what crosses, this one requires there to be a controlled crossing at all. "Untrusted" means any network you do not control, which is broader than "the internet": a partner link, a corporate wireless guest network and a supplier VPN are all untrusted. In cloud environments the NSC is the security group, the network ACL or the managed firewall, which the v4 language deliberately accommodates; what matters is that it exists, is configured deliberately, and is documented in the standards from 1.2.1.
What to prepare
- The network diagram showing where trusted meets untrusted, and what enforces each boundary.
- The NSC configurations at those points.
- The definition of what you treat as untrusted, since the assessor will test it against the diagram.
How to implement it
1. Name every boundary, not just the internet edge. Partner connections, supplier tunnels and guest networks each meet a trusted network somewhere, and those crossings are the ones missing from most diagrams.
2. Say what your NSCs are. In a cloud environment that is security groups and ACLs; writing it down avoids an assessment spent explaining that you have no appliance.
3. Keep the diagram and the configuration reconciled. A boundary on the diagram with no NSC, or an NSC at a boundary the diagram does not show, are both findings and the second is more common.
4. Do not treat internal as trusted by default. A corporate network that anyone can join is untrusted relative to the CDE, whatever it is called.
Where this commonly fails
- The internet edge controlled while a partner or supplier link is not.
- Cloud environments assumed out of scope for NSCs because there is no firewall appliance.
- Guest or corporate wireless treated as trusted because it is inside the building.
- A diagram that has not caught up with a new connection.
Related controls
Others in section 1.4:
| Control | What it requires |
|---|---|
| 1.4.2 | Inbound traffic from untrusted networks to trusted networks is restricted… |
| 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.3.3 · All controls · 1.4.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.