PCI DSS 2.2.4: Only necessary services, protocols, daemons, and functions are enabled

PCI DSS v4.0.1 control 2.2.4: 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

Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.

Summary

Turn on only what the system needs, and remove or disable everything else.

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.4.a Examine system configuration standards to verify necessary services, protocols, daemons, and functions are identified and documented.
2.2.4.b Examine system configurations to verify the following: • All unnecessary functionality is removed or disabled. • Only required functionality, as documented in the configuration standards, is enabled.

Tested in both directions, like 1.2.5 is for network services. 2.2.4.a examines the configuration standards to verify the necessary services, protocols, daemons and functions are identified and documented; 2.2.4.b examines actual system configurations to verify unnecessary functionality is removed or disabled and only required functionality is present. So the standard has to enumerate what is needed, and the system has to contain nothing beyond it. The word doing the widening is functions, which reaches past services and daemons to sample applications, default content, unused drivers and subsystems, and the demonstration pages that ship with a web server.

What to prepare

  • The configuration standard for each system type, listing required services, protocols, daemons and functions.
  • Actual configurations for a sample of each type, to compare against it.
  • The justification for anything present that the standard does not list.

How to implement it

1. Build the list from a working system, then prune. Writing it from first principles produces a standard nothing matches; starting from reality produces one that can be enforced.

2. Remove rather than disable where you can. Removed functionality cannot be re-enabled by a later change or a package update, and the requirement offers both.

3. Do not stop at services. Default sample content and unused subsystems are functions, and they are the ones a scan finds.

4. Make the base image the standard. A minimal image is the most durable way to satisfy 2.2.4.b, since every system built from it starts compliant.

Where this commonly fails

  • A standard listing services and silent on functions, so 2.2.4.a passes and the system still carries sample content.
  • Functionality disabled and re-enabled by a package update, with nothing detecting it.
  • Systems built before the standard existed and never brought into line.
  • Cloud managed services excluded, though they too expose optional functionality.

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.5 If any insecure services, protocols, or daemons are present…
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.3 · All controls · 2.2.5

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.