PCI DSS 3.7.7: Key management policies and procedures are implemented to include the prevention
PCI DSS v4.0.1 control 3.7.7: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.7.
Requirement 3: Protect Stored Account Data › Section 3.7
Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys.
Summary
Make it impossible for someone to quietly swap in a key of their own.
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 | |
|---|---|
| 3.7.7.a | Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define prevention of unauthorized substitution of cryptographic keys. |
| 3.7.7.b | Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented. |
The least intuitive control in the section, and the one most often written off as not applicable. Substitution is a specific attack: an insider replaces a legitimate key with one they control, so everything encrypted afterwards is readable by them, and nothing looks broken because encryption still works. It is not covered by the storage controls, because the attacker may be someone with legitimate access to the store. Prevention comes from the same dual-control and split-knowledge arrangement as 3.7.6, plus authorisation and logging on key-change operations. Procedure 3.7.7.b interviews personnel and/or observes processes, so a written statement that substitution is prevented needs a mechanism behind it that someone can point at.
What to prepare
- The procedure naming what prevents substitution, rather than asserting that it is prevented.
- Evidence that key changes require more than one person, or are logged and reviewed.
- The key-change log, and who reviews it.
- Key identifiers or check values that let a key be verified as the expected one.
How to implement it
1. Require two people for any key change. Dual control is the direct answer to an insider substitution and it is the same arrangement 3.7.6 already asks for where cleartext components are handled.
2. Log key operations and have someone read the log. A key replacement that appears in a log nobody reviews is recorded rather than prevented.
3. Use key check values or identifiers. Being able to confirm that the key in use is the key you expect turns substitution from invisible into detectable.
4. Do not write this off as not applicable. The control has no applicability condition, and answering it with a description of your storage controls is what an assessor pushes back on.
Where this commonly fails
- Marked not applicable, since the attack is unfamiliar and the control text is abstract.
- A single administrator able to change a key alone with no second party and no review.
- Key operations logged into a stream nobody reads.
- The procedure restating the requirement instead of naming a mechanism, which 3.7.7.b will expose.
Related controls
Others in section 3.7:
| Control | What it requires |
|---|---|
| 3.7.1 | Key-management policies and procedures are implemented to include generation of strong… |
| 3.7.2 | Key-management policies and procedures are implemented to include secure distribution… |
| 3.7.3 | Key-management policies and procedures are implemented to include secure storage… |
| 3.7.4 | Key management policies and procedures are implemented for cryptographic key changes for keys… |
| 3.7.5 | Key management policies procedures are implemented to include the retirement, replacement… |
| 3.7.6 | Where manual cleartext cryptographic key-management operations are performed by personnel… |
| 3.7.8 | Key management policies and procedures are implemented to include that cryptographic key… |
| 3.7.9 | Service providers: Where a service provider shares cryptographic keys with its customers for transmission… |
← 3.7.6 · All controls · 3.7.8 →
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.