PCI DSS 1.2.5: All services, protocols, and ports allowed are identified, approved
PCI DSS v4.0.1 control 1.2.5: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 1.2.
Requirement 1: Install and Maintain Network Security Controls › Section 1.2
All services, protocols, and ports allowed are identified, approved, and have a defined business need.
Summary
Have a list of every service, protocol and port you allow, with a business reason and an approval for each, and let nothing else through.
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.2.5.a | Examine documentation to verify that a list exists of all allowed services, protocols, and ports, including business justification and approval for each. |
| 1.2.5.b | Examine configuration settings for NSCs to verify that only approved services, protocols, and ports are in use. |
This control is tested in both directions and that is the whole of it. Procedure 1.2.5.a examines the documentation for a list with justification and approval; 1.2.5.b examines the NSC configuration to verify that only approved services, protocols and ports are in use. So the list must cover everything running, and nothing running may be off the list. Most entities have a list that is a genuine subset of reality, which passes the first procedure and fails the second. It is the input to 1.2.6, which asks what you do about the ones on the list that are insecure, and to 1.2.7, which is the review that keeps it true.
What to prepare
- The list itself: service, protocol, port, business need, approver, date.
- Current NSC rulesets, so the list and the configuration can be compared.
- The approver for each entry, and their authority to approve it.
How to implement it
1. Build the list from the configuration, not from memory. Export the rules and work back. Building it the other way produces a document describing an intended network rather than the one you have.
2. Write a business need a non-engineer can evaluate. "Required for the application" is what the assessor pushes back on. Naming the system at each end and what the traffic does is what stands.
3. Reconcile the two on a schedule. The gap between list and configuration opens continuously, and 1.2.7 gives you a six-monthly point at which to close it.
4. Delete rather than justify. Every entry you remove is one you no longer have to defend, and the usual first pass over an old ruleset removes more than it justifies.
Where this commonly fails
- A list that covers the deliberate rules and omits everything added under pressure, which is precisely the population 1.2.5.b surfaces.
- Approvals recorded as a team name rather than a person with the authority to give them.
- Broad rules such as an any-port permit between two segments, which cannot be given a business need for each port because nobody knows which ports are in use.
- The list maintained for the perimeter firewall only, when the control covers all allowed services, protocols and ports.
Related controls
Others in section 1.2:
| Control | What it requires |
|---|---|
| 1.2.1 | Configuration standards for NSC rulesets… |
| 1.2.2 | All changes to network connections and to configurations of NSCs are approved and managed… |
| 1.2.3 | An accurate network diagram(s) is maintained that shows all connections between the CDE… |
| 1.2.4 | An accurate data-flow diagram(s) is maintained that meets… |
| 1.2.6 | Security features are defined and implemented for all services, protocols… |
| 1.2.7 | Configurations of NSCs are reviewed at least once every six months to confirm they are relevant… |
| 1.2.8 | Configuration files for NSCs… |
← 1.2.4 · All controls · 1.2.6 →
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.