PCI DSS 1.2.8: Configuration files for NSCs
PCI DSS v4.0.1 control 1.2.8: the requirement in full, the 1 testing procedure 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
Configuration files for NSCs are:
- Secured from unauthorized access.
- Kept consistent with active network configurations.
Summary
Configuration files for your network security controls are protected from unauthorised access, and they match what the device is actually running.
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.8 | Examine configuration files for NSCs to verify they are in accordance with all elements specified in this requirement. |
Two elements, and the second is the interesting one. Kept consistent with active network configurations is aimed at the gap between the saved configuration and the running one. On network hardware that is the difference between startup-config and running-config, and it means a device that reboots comes up enforcing a different ruleset than the one you reviewed. In a cloud or infrastructure-as-code environment it is state drift: the repository says one thing and the console says another, so 1.2.7 reviewed a file rather than a network. "Configuration files" is broader than the device: backups, exported rulesets and IaC repositories are all configuration files, and they hold the same information as the device with none of its access control. It is the file-level counterpart of 1.2.1, which is about the standards those configurations implement.
What to prepare
- The list of locations configuration files exist in: devices, backup stores, repositories, exports.
- Access permissions for each, showing who can read as well as who can write.
- A comparison of saved against running configuration for a sample of devices.
How to implement it
1. Write the running configuration to the saved one as part of the change, not later. The drift is created by the last person to make a change under time pressure, and it is invisible until a reboot applies it.
2. Restrict read access, not only write access. A firewall configuration is a map of your network with the exceptions marked. Backups on a shared drive that the whole IT department can open satisfy nobody's definition of secured from unauthorised access.
3. Detect drift rather than assuming it away. A scheduled comparison of saved to running, or a plan run in an infrastructure-as-code pipeline, turns this into an alert instead of an annual discovery.
4. Cover the repositories. If rules live in version control, that repository is a configuration file store and its access control is in scope for this requirement.
Where this commonly fails
- Running configuration changed and never saved, so the enforced ruleset differs from the reviewed one after any restart.
- Configuration backups in a general-purpose file share with broad read access.
- Infrastructure-as-code drift, where manual console changes were never brought back into the repository.
- Old configuration exports left in a ticket or an email attachment, which are configuration files too.
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.6 | Security features are defined and implemented for all services, protocols… |
| 1.2.7 | Configurations of NSCs are reviewed at least once every six months to confirm they are relevant… |
← 1.2.7 · All controls · 1.3.1 →
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.