While some organizations haven’t yet finished their PCI 3.1 audits, the new PCI DSS 3.2 has already been released by the PCI council. It includes more stringent compliance rules requiring multifactor authentication, extra validation procedures for service providers and much-needed clarifications about masking criteria for primary account numbers (PAN) when displayed.
As is typical with each new version of the DSS, there are many incremental changes, control consolidations and clarifications. What is not typical is the release of a new version so close to the previous iteration. I believe this was done by the council by design. The source of too many breaches came from third-party service providers. The council moved to tighten the requirements on these entities.
Key new controls that impact service providers range across the spectrum from governance to technical. For example, the new 12.4 requires that executive management formally acknowledge the responsibility for protecting cardholder data and for establishing a PCI compliance program.
On the technical side, service providers must now conduct penetration testing to validate their segmentation controls every six months, as well as implement processes for detecting and reporting on security control failures.
Likely, the most difficult new control for service providers is 12.11, which requires them to perform quarterly reviews of their security policies and operational procedures to confirm that personnel are following both. This will significantly increase the resources required by service providers’ internal audit departments to establish testing methodologies to demonstrate and conduct the quarterly testing.
Since there is no guidance yet on whether this applies to all employees every quarter, larger service providers could be significantly impacted. This control will also require more effort from QSAs during assessments to be able to determine if the reviews have the requisite rigor and coverage to meet this somewhat broad, sweeping control.
These changes will ultimately lead to better security programs and fewer breaches; albeit at no small cost.
Review the table below for new proposed requirements. The guidance also proposes changes or clarifications to dozens of sections not listed below.
New PCI DSS 3.2 GuidanceThis table only discusses new additions to PCI DSS 3.2. The below is for information only and final reliance should be based on the officially published documents by the PCI Security Standards Council. |
||
| Section | Details | Impact |
| 3.5.1 | New requirement for service providers to maintain a documented description of the cryptographic architecture; effective February 1, 2018. | Any service provider that is providing an encryption solution must maintain detailed documentation on their architecture, including key management. This is likely to expose many providers that rely on less-than-robust solutions, such as whole-disk encryption, or rely on the underlying encryption built into many SAN solutions that don’t offer any protection for running servers. |
| 6.4.6 | New requirement for change control processes to include verification of PCI DSS requirements impacted by a change; effective February 1, 2018. | This is a significant addition to the requirements and will force all PCI entities to add an analysis of the potential impact on PCI controls for every change within a CDE. It’s good to see a grace period as this will force a re-write of change control policies and technical changes to processes and procedures — neither of which are trivial efforts. |
| 8.3.1 | New Requirement 8.3.1 addresses multi-factor authentication for all personnel with non-console administrative access to the CDE; effective February 1, 2018. | These expand the multi-factor requirement to all types of administrative access, including application administration, and will require technical changes to facilitate. The grace period will allow the necessary time to implement significant technical changes to their environments. |
| 8.3.2 | New Requirement 8.3.2 addresses multi-factor authentication for all personnel with remote access to the CDE (incorporates former Requirement 8.3). | |
| 10.8, 10.8.1 | New requirement for service providers to detect and report on failures of critical security control systems; effective February 1, 2018. | This is another significant change that will impact the formalization and documentation of processes and procedures. New processes may even need to be created. |
| 11.3.4.1 | New requirement for service providers to perform penetration testing on segmentation controls at least every six months; effective February 1, 2018. | This requirement will result in higher expenses for service providers and may lead to some price increases. |
| 12.4 | New requirement for service providers’ executive management to establish responsibilities for the protection of cardholder data and a PCI DSS compliance program; effective February 1, 2018. | This requires executive management to formally acknowledge the responsibility for protecting cardholder data (CHD), as well as formally authorizing and sponsoring the PCI compliance program. This will likely add to the liability of executive management in publicly traded companies. |
| 12.11 | New requirement for service providers to perform reviews at least quarterly to confirm personnel are following security policies and operational procedures; effective February 1, 2018. | While it doesn’t seem too significant at the surface, this requirement will require a much higher level of formal diligence and documentation. It will significantly increase the burden on internal audit staff to develop, implement and document testing procedures. The grace period will help, but many smaller organizations that lack large (if any) IT security departments will be very hard pressed to meet this new requirement. |