PCI DSS 2.2.6: System security parameters are configured to prevent misuse
PCI DSS v4.0.1 control 2.2.6: the requirement in full, the 3 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
System security parameters are configured to prevent misuse.
Summary
Set the security parameters on each system so it cannot be misused, and make sure your administrators know what those parameters are.
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.6.a | Examine system configuration standards to verify they include configuring system security parameters to prevent misuse. |
| 2.2.6.b | Interview system administrators and/or security managers to verify they have knowledge of common security parameter settings for system components. |
| 2.2.6.c | Examine system configurations to verify that common security parameters are set appropriately and in accordance with the system configuration standards. |
The vaguest-looking control in the section and the one with the most unusual test. 2.2.6.b interviews system administrators or security managers to verify they have knowledge of common security parameter settings, so this control is assessed partly on what the people know rather than on what the systems are set to. An entity can run well-hardened systems and still struggle here if hardening was applied once from a downloaded benchmark and nobody can explain the settings. The other two procedures are the familiar pair: 2.2.6.a examines the standards for the parameters, 2.2.6.c examines the systems for them being set accordingly.
What to prepare
- The security parameters named in each configuration standard, per system type.
- System configurations showing those parameters set.
- Administrators available to be interviewed about them.
- The benchmark or source the parameters came from, so the choices can be explained.
How to implement it
1. Record why each parameter is set the way it is. It is what turns an interview from a memory test into a conversation, and it survives the administrator who chose it leaving.
2. Base the standard on a recognised benchmark and say which. It gives the parameters a provenance and gives administrators something to read.
3. Keep the standard and the systems in step. 2.2.6.c compares them, so a benchmark applied at build and a standard written afterwards will disagree.
4. Brief the team, not just the author. The interview may reach any administrator, and knowledge concentrated in one person is a single point of failure for this control and for the environment.
Where this commonly fails
- Hardening applied from a benchmark nobody can name or explain.
- Parameters set on the systems and absent from the standards, so 2.2.6.a fails while the systems are fine.
- Knowledge held by one administrator, which the interview will find if it reaches anyone else.
- Standards written generically, without naming the actual parameters for each platform.
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.5 | If any insecure services, protocols, or daemons are present… |
| 2.2.7 | All non-console administrative access is encrypted using strong cryptography |
← 2.2.5 · All controls · 2.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.