PCI DSS 2.2.5: If any insecure services, protocols, or daemons are present
PCI DSS v4.0.1 control 2.2.5: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 2.2.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.2
If any insecure services, protocols, or daemons are present:
- Business justification is documented.
- Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.
Summary
If an insecure service, protocol or daemon is running, justify it in writing and implement something that reduces the risk.
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 | |
|---|---|
| 2.2.5.a | If any insecure services, protocols, or daemons are present, examine system configuration standards and interview personnel to verify they are managed and implemented in accordance with all elements specified in this requirement. |
| 2.2.5.b | If any insecure services, protocols, or daemons, are present, examine configuration settings to verify that additional security features are implemented to reduce the risk of using insecure services, daemons, and protocols. |
The system-level twin of 1.2.6. That control is about insecure protocols the network permits; this one is about what is running on the system, and an entity can pass one and fail the other. Two elements, both required: a documented business justification, and additional security features documented and implemented, which 2.2.5.b examines in the configuration. As in 1.2.6, the standard supplies no list of what counts as insecure, so identifying them is your judgement and your documentation. The control is conditional on such services being present, which makes "we have none" a checkable claim rather than a way out: it is verifiable against the enumeration 2.2.4 already requires.
What to prepare
- The identification of insecure services, protocols and daemons in use, with the reasoning.
- A business justification for each.
- The additional security feature defined for each, and configuration showing it implemented.
How to implement it
1. Name them honestly and check against 2.2.4. The list of what is enabled is where an unclaimed insecure daemon shows up.
2. Match the mitigation to how the protocol fails. A clear-text protocol is mitigated by an encrypted transport or by isolation, not by restricting who may connect, which does nothing about interception.
3. Prefer removal. Every one retired is one fewer to justify, mitigate, evidence and defend each year.
4. Document the feature as well as configuring it. Both elements say documented and implemented, and 2.2.5.a examines the standards while 2.2.5.b examines the settings.
Where this commonly fails
- Claiming none are present while the enabled-services list shows otherwise.
- A mitigation implemented and never documented, or documented and never implemented.
- Management and administration protocols exempted informally because they are internal.
- Justifications written once for a system that has since changed role.
Related controls
Others in section 2.2:
| Control | What it requires |
|---|---|
| 2.2.1 | Configuration standards are developed, implemented, and maintained… |
| 2.2.2 | Vendor default accounts… |
| 2.2.3 | Primary functions requiring different security levels… |
| 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled… |
| 2.2.6 | System security parameters are configured to prevent misuse |
| 2.2.7 | All non-console administrative access is encrypted using strong cryptography |
← 2.2.4 · All controls · 2.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.