Version 3.2 of the PCI DSS was released in April 2016 with several updates intended to better protect organizations from data breaches and help clarify some previous points of confusion within the standard.
On Oct 31, 2016, PCI DSS version 3.1 was retired and all new assessments were to be completed utilizing the version 3.2 SAQs. Beginning on February 1, 2018, many of the changes in version 3.2, previously considered best practice by the PCI SSC, will become requirements so it is important that you are taking steps to meet these requirements as soon as possible.
What changes will become requirements on February 1, 2018?
Change Control (Requirement 6.4.6)
Upon completion of a significant change made to a system or device within the cardholder data environment (CDE), all appropriate PCI DSS controls must be applied to the now in-scope environment. This requirement helps ensure processes are in place to maintain device inventories as new systems are introduced, maintain configuration standards, and verify that all appropriate security controls are applied.
Multi-Factor Authentication (Requirement 8.3)
Previously, the PCI DSS required only untrusted, remote access into the cardholder data environment use two-factor authentication. In Version 3.2, the term was updated to multi-factor authentication (MFA) to clarify that at least two different factors must be used when authenticating remote access to the CDE (something you know, something you have, or something you are). The requirement has also been extended to include any personnel with administrative access into the cardholder data environment.
Requirement 11.3.4 states that if your organization is utilizing segmentation to limit the scope of your CDE, penetration tests on segmentation controls must be performed annually by an organizationally-independent resource (new requirement now includes SAQ B-IP and SAQ C-VT merchants). Service providers will now be required to perform segmentation tests at least every six months. These are not full penetration tests, but rather a smaller test to verify that your segmentation controls are limiting access as designed.
Additional Changes for Service Providers:
Requirement 3.5.1 – Service providers need to maintain a documented description of cryptographic architectures, including the details of all algorithms, protocols, and keys used for the protection of cardholder data, a description of the key usage for each key, and an inventory of any hardware security modules (HSM) or other secure cryptographic devices (SCDs) used for key management.
Requirement 10.8 – Service providers are required to implement a timely detection and alerting process to identify failure of critical security controls systems, such as firewalls, IDS/IPS, file integrity monitoring, anti-virus, physical or logical access controls, audit logging mechanisms, and/or segmentation controls.
Requirement 12.4.1 – Service providers must establish responsibilities for the protection of cardholder data, ensuring overall accountability for maintaining compliance, and define a PCI compliance program that includes both a charter for the program as well as details for all communication to executive management.
Requirement 12.11 – Service providers must perform quarterly reviews to confirm personnel are following PCI-related security policies and operational procedures.
Migration from SSL & TLS v1.0 to TLS v1.2
Is your organization using SSL/early TLS as a security control to protect your cardholder data environment (CDE)? Migration to TLS v1.2 (from SSL & TLS v1.0) is not required by the PCI SSC until June 30, 2018, but if you are using it now, you must have a formal Risk Mitigation and Migration Plan (RMMP) in place. If you have quarterly ASV scans performed by CampusGuard and are still using SSL/early TLS, then you will be asked to provide a copy of that document.
If you do not have a plan in place, refer to the PCI Council’s Information Supplement, Migrating from SSL and Early TLS. This guidance document outlines the information that must be reviewed, provides examples of the details that should be documented within the RMMP, and includes suggested migration options. You can also reach out to your CampusGuard Team for assistance with your migration plan or if you would like the ASV Team to review your documentation prior to your next scheduled vulnerability scan.
If you haven’t already addressed these requirements, there is still time before February 1, 2018. Don’t hesitate to contact your CRM Team at firstname.lastname@example.org if you want to discuss how these changes may or may not apply within your merchant environments.
Some additional guidance from our Security Advisor team below:
[Wheeler]: Although these new requirements will need to be in place as of February 1, 2018, they have been out for a while now. If you are behind the power curve, right now is the time to plan implementation, before the holidays arrive. In regards to segmentation testing – although segmentation testing may be new to you (depending on your merchant level), this must be performed after major network changes as well.