The Payment Card Industry Security Standards Council (PCI SSC) recently released version 3.2 of their Data Security Standard (PCI DSS v3.2). The PCI DSS is a global standard designed to protect payment card data. It applies to any organization that accepts or processes payment cards, and lays out a comprehensive compliance program designed to define how organizations should implement security controls to protect payment card records. We will be looking at the “evolving” requirements and clarifications that could have an impact on both technology and business processes, though the council has delayed enforcement of compliance with these newer requirements until February 1st 2018, which means that the required control must be implemented and effective on that date.
The majority of the new requirements in v3.2 are intended to clarify the obligations of PCI DSS validated service providers, which is a reflection of the increasing importance of these providers in the PCI DSS ecosystem.
Changes that impact service providers
Cryptographic architecture must be fully documented (requirement 3.5.1)
Service providers have previously been required to meet all cryptographic requirements, such as key management and key generation. But, they were not explicitly obligated to maintain documentation of the cryptographic processes. This new rule eliminates that gap, which should enable Qualified Security Assessors (QSAs) and other auditors to better validate a service provider’s compliance.
Implement a process for the detection, reporting and investigation of critical security control systems failures (requirement 10.8, 10.8.1)
While PCI DSS version 3.1 required that policies and procedures for monitoring be defined, these additional requirements compel service providers to implement a process to verify that any failure or incident in the core security controls is documented, remediated, and a risk assessment and investigation is performed to determine root cause and prevent further occurrences.
Perform penetration testing on segmentation controls every six months or after any change to segmentation (requirement 220.127.116.11)
Penetration testing has been required on an annual basis since PCI DSS version 1.0, with the purpose of verifying that shared environments are isolated. This new requirement strengthens that control, which will mean that additional effort and cost is now required by service providers to schedule and execute penetration testing at a minimum of every six months.
Implement quarterly reviews to verify security and operational polices/procedures are being followed (requirement 12.11, 12.11.1)
Service providers will need to implement a new process for verifying that security activities are being performed in alignment with security policies and procedures at a minimum of every three months. This process also needs to create documentation of the quarterly review, including the signoff process. The purpose of this new requirement is to verify that security controls are being performed as intended, but will create additional for individuals responsible for PCI compliance to report.
Changes that impact all entities
Significant changes must trigger a documentation update to reflect the new reality (requirement 6.4.6)
When a significant change is required within the PCI DSS environment, additional change control documentation is now required as part of the change management process. The purpose behind this control is to verify that changes effecting applicable PCI DSS requirements are tracked, and identified controls are updated. While this was always a good practice, now that the requirement has been formally defined, this may increase the change management process timeline and administrative overhead as affected PCI DSS controls will need to be identified, updated, and documented.
Multifactor authentication (MFA) is required for all types of administrator access (requirement 8.3.1)
Previously, MFA has been a requirement when accessing a cardholder data environment (CDE) from outside the network. The new version of PCI DSS version 3.2 now requires MFA for all personnel with “non-console administrative access” into the cardholder data environment. In other words, any administrator access at the network, system, or application level must now use MFA to log in; however, MFA is not required to sign in multiple times at both network and system / application level for a system component. The purpose of this requirement is improve the security by requiring MFA on all system components where administrative functions are performed. However, the exact approach to this control is dependent on the current architecture and applications in use.
The change to the MFA requirement is the most significant change to PCI DSS version 3.2, with wide-ranging implications for both service providers and merchants, whilst other changes to the standard will also create some additional administrative overhead, particularly for service providers. The complete list of alterations to the standard including evolving, clarification, and additional guidance requirements can be found here. If you’re curious as to how WMP sees clients designing and implementing to meet the PCI DSS requirements, we’ll be starting a series of posts next week addressing some specific implementation challenges of PCI DSS, as well as some examples from one of our recent projects. Check back for more information!