PCI DSS 1.2.6: Security features are defined and implemented for all services, protocols
PCI DSS v4.0.1 control 1.2.6: 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
Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.
Summary
For any insecure service, protocol or port you still use, define what mitigates the risk and actually implement it.
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.6.a | Examine documentation that identifies all insecure services, protocols, and ports in use to verify that for each, security features are defined to mitigate the risk. |
| 1.2.6.b | Examine configuration settings for NSCs to verify that the defined security features are implemented for each identified insecure service, protocol, and port. |
The standard does not ban insecure protocols here. It requires that you have named them and that something mitigates the risk. Two consequences follow. First, there is no list of insecure protocols in the requirement, so identifying them is your judgement and your documentation: procedure 1.2.6.a examines "documentation that identifies all insecure services, protocols, and ports in use", which you have to have produced. Second, 1.2.6.a and 1.2.6.b are define and implement, tested separately, so a documented mitigation that was never configured fails half the control. Declaring that you use none is the common shortcut, and it is checkable against the list from 1.2.5.
What to prepare
- The documented identification of insecure services, protocols and ports in use, with the reasoning.
- The mitigating security feature defined for each.
- NSC configuration showing that feature implemented, since 1.2.6.b examines configuration and not intent.
How to implement it
1. Name them honestly. Telnet, FTP, SNMP v1 and v2c, SMBv1, unauthenticated LDAP and anything running plain HTTP inside the environment are the usual finds. An environment of any age has some, and claiming none invites the assessor to look for one.
2. Match the mitigation to how the protocol actually fails. A protocol that sends credentials in clear text is mitigated by an encrypted transport or by isolating the segment, not by restricting the source address, which does nothing about interception.
3. Prefer removing it. Every insecure protocol you retire is one you no longer document, mitigate, evidence and defend each year.
4. Record the decision, not just the setting. The control asks that security features are defined, and a firewall rule with no explanation of what risk it addresses is a setting rather than a defined feature.
Where this commonly fails
- Declaring no insecure protocols are in use while the ruleset from 1.2.5 shows otherwise.
- A mitigation defined in a document and never applied to the device, which fails 1.2.6.b.
- Management protocols exempted informally because they are internal, when internal is where most of them run.
- Mitigations that address the wrong failure, such as source restriction for a clear-text protocol.
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.5 | All services, protocols, and ports allowed are identified, approved… |
| 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.5 · All controls · 1.2.7 →
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.