Introduction – A new version of the PCI DSS
With the April release of Payment Card Industry Data Security Standard (PCI DSS) version 3.2, organisations should now be reviewing their PCI compliance obligations. This article explains some of the key DSS changes that PCI DSS-compliant organisations should understand.
To ease the pain of the review process, the Standards Security Council (SSC) provides a summary of the changes in their on-line document library. You can get to the library at the following URL:
You can find the latest “PCI DSS Summary of Changes” document in the “Supporting Documents” section of the library.
Details regarding the changes
There are 58 changes between v3.1 and v3.2 of the DSS. The vast majority of those (51 in total) are minor changes which provide extra clarification about the intent of controls, and which also provide additional guidance on various topics. While these changes should be reviewed, they are unlikely to affect an organisation’s compliance in a major way.
The remaining 7 changes are the big ticket items. These changes could impact an organisation’s PCI DSS compliance program in a significant manner as they introduce new requirements or substantially modify existing requirements.
As always, the new requirements are initially added in as “best practices”. This gives organisations time to plan for and implement changes before the requirements become mandatory. In this case the new requirements become mandatory on February 1, 2018.
The 7 major changes, 6 of which are targeted at service providers, are discussed below:
New requirement 3.5.1 (Service providers only)
3.5.1 Maintain a documented description of the cryptographic architecture that includes:
- Details of all algorithms, protocols and keys used for the protection of cardholder data, including key strength and expiry date.
- Description of the key usage for each key.
- Inventory of any HSMs and other SCDs used for key management.
This requirement is designed to assist service providers in maintaining and managing their cryptographic systems more effectively, by ensuring that the relevant documentation is kept current. Up-to-date information allows the organisation to more effectively monitor the threat environment for issues related to their specific cryptographic architecture; it also allows the organisation to plan for updates and revisions as required.
Introduction of the new control will likely have only a minimal impact to the organisation’s operations because the control merely mandates formal documentation of cryptographic systems which older versions of the DSS have already demanded be in place.
New requirement 6.4.6
6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
This control is designed to ensure that PCI DSS requirements are explicitly included in the organisation’s current change management processes; the control assists the entity in maintaining visibility into the compliance state of CDE systems.
The new control will introduce some additional overhead into organisation’s change management processes and procedures by the inclusion of an extra step to validate that device inventories and configuration standards are kept up to date and that security controls are applied where necessary.
Modified requirement 8.3 (Service providers only)
Requirement 8.3 has been restructured and divided into two sub-requirements, 8.3.1 and 8.3.2.
8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.
Sub-requirement 8.3.1 is a new control. It states that multi-factor authentication must now be used for ALL non-console administrative access into the CDE, rather than requiring multi-factor for just remote access, as was the case for requirement 8.3 in the previous version of the standard.
The introduction of this control may require significant changes to the organisation’s system administration processes and procedures, depending on the current structure of the CDE. For example, if administrator desktops are currently used to directly access CDE systems, then multi-factor authentication mechanisms may have to be introduced onto all CDE systems and components to fulfil this requirement.
8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support and maintenance) originating from outside the entity’s network.
Sub-requirement 8.3.2 is essentially the old 8.3 requirement reworded slightly. Importantly, as this is not technically a new requirement it does not enjoy best practice status and is mandatory immediately.
New requirement 10.8 (Service providers only)
10.8: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
- Physical and logical access controls.
- Audit logging mechanisms.
- Segmentation controls.
10.8.1 Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:
- Restoring security functions.
- Identifying and documenting the duration, root cause and remediation of the security failure.
- Identifying and addressing any security issues that arose during the failure.
- Performing a risk assessment to determine whether further actions are required as a result of the security failure.
- Implementing controls to prevent cause of failure from reoccurring.
- Resuming monitoring of security controls.
While other PCI DSS requirements focus on the monitoring and alerting of information produced by critical security control systems, the new requirements focus on monitoring of those control systems themselves. Obviously it is very important to know when a critical control fails so that the issue may be rectified as soon as possible. An undetected failure of a security control mechanism may provide a potential attacker with opportunity to compromise systems and steal or otherwise misuse sensitive data from components within the CDE.
Ideally, and depending on the maturity of the organisation in question, implementation of these controls should require little extra administrative overhead as they should just be an extension to the existing logging and monitoring framework.
New requirement 220.127.116.11 (Service providers only)
If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.
This new control mandates that service providers must perform penetration tests of their segmentation controls every six months rather than only testing them as part of the required annual penetration testing.
Implementation of this control should only result in a minimal increase in overhead as the penetration testing mechanisms should already be in place.
New requirement 12.4.1 (Service providers only)
Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
- Overall accountability for maintaining PCI DSS compliance.
- Defining a charter for a PCI DSS compliance program and communication to executive management.
This control was introduced to ensure that organisations formally assign responsibility to executive management personnel or teams for the management and maintenance of an entity’s PCI DSS compliance program.
Assigning this responsibility to senior management ensures that policies and procedures supporting the protection of cardholder data are included into the entity’s strategic agenda, while also demonstrating management’s commitment CHD security.
Introduction of this control will incur some extra overhead during the implementation of the program, and creation and management of the charter.
New requirement 12.11 (Service providers only)
12.11 Perform reviews at least quarterly to confirm personnel are following security policies and operation procedures. Reviews must cover the following processes:
- Daily log reviews.
- Firewall rule-set reviews.
- Applying configuration standards to new systems.
- Responding to security alerts.
- Change management processes.
12.11.1 Maintain documentation of a quarterly review process to include:
- Documenting results of the reviews.
- Review and sign-off of results by personnel responsible for the PCI DSS compliance program.
These new controls are designed to provide management with some visibility into the effectiveness of the listed PCI DSS controls which are already in place. This ties in nicely with the new requirement 12.4.1, which requires executive management to become responsible for the organisation’s PCI DSS compliance program.
The entity’s compliance team would normally be responsible for enacting these audit processes. Some extra, ongoing overhead is likely to be incurred implementing of these controls.
A new version of the PCI DSS (v3.2) was released on April 28, 2016. There is a 6-month period following that date for which v3.1 of the DSS can still be used but after that, v3.2 will have to be used for all new assessments. You can read more about the DSS at:
Of the 58 changes listed, the vast majority (51 in total) are minor changes which provide extra clarification about the intent of controls, and which also provide additional guidance on various topics. While these changes should be reviewed, they are unlikely to cause major compliance issues for most mature organisations.