PCI Requirement Changes Coming in 2018

The end of 2017 is quickly approaching, and we thought we should remind you of the PCI requirement changes that are coming next year. Some of these deadlines will go into effect at the end of January, so if you are not on top of these you had better get moving.

As of February 1, 2018, the following will become requirements for all organizations complying with the PCI DSS.

Merchants and Service Providers

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 requirement mandates that significant changes need to be identified and the QSA must be able to then ensure that all relevant PCI requirements were completed because of these significant changes. The biggest impacts here are related to:

• Having a documented definition for what your organization considers a “significant change”
• Being able to identify and document all significant changes through your change management system
• Being able to prove that vulnerability scanning (11.2.3), penetration testing (11.3.1 and 11.3.2) and risk assessment updates (12.2) were conducted as a result of the significant change

This change is to address issues the Council has found through their quality management reviews of assessments that are too often finding that organizations are not following the significant change portions of these requirements.

8.3.1 – Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access.

This change should be self-explanatory but we still are getting questions about it. This requirement change is mandating that all non-console administrative access to systems/devices in the cardholder data environment (CDE) requires some form of multi-factor authentication (MFA). What this requirement mandates is MFA for all administrators of CDE systems/devices.

Where we continue to get questions is the difference between 8.3.1 and 8.3.2 which requires MFA for remote access. For an administrator that is on the internal network, requirement 8.3.1 means they will need to use MFA to gain administrative access to any CDE system or device. If that same administrator is working from home, 8.3.1 means that they will have to use MFA to get connected to the internal network and then use MFA again to gain administrative access to any CDE system or device. The same MFA solution can be employed, but that will mean that time delays between the remote connection and the CDE connection will have to be implemented to ensure that MFA factors are not reused.

The rationale behind this change is to minimize all of the breaches that have occurred due to spear phishing of administrators.

In addition to these two changes, the following changes are specific only to service providers.

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; and inventory of any hardware security modules (HSM) and other secure cryptographic devices (SCD) used for key management.

QSAs are now going to need to gather detailed documentation regarding how service providers have implemented all of their encryption. That documentation will include the architecture of all encryption solutions, all encryption protocols used, key bit strengths for all keys and an inventory of all encryption key management and generation systems/devices.

This is to address the prevalence of service providers offering end-to-end encryption (E2EE) solutions to their customers that are not validated to the Council’s P2PE standard. The Council has been finding that some of these solutions are not using proper cryptographic solutions and practices that results in leaving cardholder data exposed.

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: firewalls, intrusion detection/prevention systems, file integrity monitoring, anti-virus, physical access controls, logical access controls, audit logging mechanisms, and segmentation controls (if used).

The Council is now specifically demanding that QSAs obtain explicit proof from service providers that their critical security control systems are providing alerts when they have failed. As a result, service providers will have to provide proof (screen shot, log data, etc.) that when such solutions fail, there is some sort of alert generated for that failure.

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 (date and time start to end) of the security failure; identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause; 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.

Going even deeper into critical security solution failures, not only does a QSA need proof of the alerts from 10.8, but they also will need proof that personnel responded to the failure in a timely manner. Such evidence is usually contained in Help Desk ticketing systems, so those tickets for each of the devices listed in 10.8 will have to be obtained along with the root cause analysis and all other relevant documentation.

11.3.4.1 – 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 is the one change we expect will get missed going forward, particularly testing outside of the six month window. The Council is requiring service providers to penetration test network segmentation controls every six months or if changes are made that would affect those controls. This change is also indirectly tied to 6.4.6 in that QSAs will most likely use the results obtained in 6.4.6 to drive whether or not any of those significant changes should have resulted in a penetration test on the network segmentation controls outside of the six-month testing window.

12.4.1 – 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.

QSAs are now required to obtain explicit documentation for a service provider’s PCI compliance program including responsibilities for PCI compliance, accountability for PCI compliance and communications to executive management regarding PCI compliance.

12.11 – Perform reviews at least quarterly to confirm personnel are following security policies and operational 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.

This is likely the most contentious of the changes being made. Service providers are required to conduct quarterly reviews to confirm that all PCI relevant security policies, standards and procedures are being followed by all personnel. As with vulnerability scanning, we expect the Council will want these reviews conducted as close to 90 days apart as possible.

12.11.1 – Maintain documentation of quarterly review process to include: documenting results of the reviews; review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program

This will require all of the documentation mentioned in the requirement be provided to the QSA to support that the reviews are being performed to satisfy compliance with 12.11.

Do Not Forget June 2018

And just so it does not get lost in the shuffle, we would be remiss if we did not remind everyone that June 30, 2018 will be the last day to use SSLv3 and TLS v1.0. Although, there was an announcement from the 2017 European Community Meeting in October that this deadline is under review by the Council. However, until the Council issues an official update, we would recommend that you plan for not supporting these two protocols past that date or have appropriate compensating controls to address the risk.