Were you the kid who came straight home from school and started the new project on the day it was assigned? Or were you the type who would calculate in your head exactly how much you could procrastinate before starting? Playing that new video game or riding bikes outside with your friends always seemed like more fun than a new compliance requirement, er, homework.

The PCI Security Standards Council released the newest version of the PCI DSS in April 2016. It contained quite a few minor changes and updates as well as nine brand new requirements. After pushing the SSL/TLS migration deadlines back due to industry pressure and tight implementation deadlines, they prudently provided almost two years of lead time for the enforcement of these new controls. The grace period is almost over. All new requirements introduced in the PCI DSS v3.2 are a best practice currently and will go into effect as of February 1, 2018.

(Note, while the controls must be in place as of February 2018, many organizations will not have to prove compliance until their regular annual window for their PCI Assessment *OR* if there is a breach or investigation prior to said assessment. Hopefully the former.)

New Requirements for Everyone

PCI DSS added two requirements that impact any entity that must comply with the standard. The first is an additional verification step in the change management process:

Requirement 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

Based on the testing procedures and guidance, there appears to be two purposes behind this requirement. Change management can be a complex process and it is good practice to verify that the change performed included the appropriate security configurations to help minimize system and network vulnerabilities. It also reminds the security and compliance teams to update ancillary documentation like asset inventories and network diagrams. Accurate documentation creates better comprehension of the environment and can accelerate response to security events.

The second new requirement regards multi-factor authentication (formerly known as two-factor authentication):

Requirement 8.3.1

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

The terminology change to “multi-factor” is a nice update that is more general and less limiting than “two-factor.” However, the actual new control is the requirement of multi-factor authentication (MFA) for “all non-console access.” Previously, MFA was only required for remote access into the Cardholder Data Environment (CDE). This means that any users with privileged access to the CDE, whether that is from a laptop at home or hard-lined into the corporate LAN, must authenticate with at least two factors. This is often solved with an internal bastion host, but make sure to review and consider the guidance on scoping and segmentation published last year by the PCI SSC. The brevity of this requirement betrays the complexity of implementing MFA in some environments.

New Requirements for Service Providers

Service providers are definitely bearing the brunt of the new requirements. They get seven new requirements especially tailored for them. These requirements will increase the security and compliance management overhead.

The first new requirement tackles documentation of encryption processes. The QSA typically pulls these details together during the assessment but the documentation is rarely all in one location. Keep in mind this would be great intel for a malicious individual. Protect this documentation appropriately and share it sparingly.

Requirement 3.5.1

Additional requirement for service providers only: 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

The new requirements in 10.8 require processes to show how critical security controls are monitored for failure and the response procedures. The testing procedures require the QSA to examine security logs and alerts for failure and then determine if appropriate responses were followed. Hopefully there are not major failures to review during every assessment. But there will likely be a raised eyebrow if informed that no security controls failed at any point during the previous year.

Requirement 10.8

Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:

• Firewalls
• IDS/IPS
• FIM
• Anti-virus
• Physical access controls
• Logical access controls
• Audit logging mechanisms
• Segmentation controls (if used)

Requirement 10.8

Additional requirement for service providers only: 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

Requirement 11.3.4.1 increases segmentation verification through penetration testing from annually to every six months. Annual penetration testing has become the industry de facto period. Just doubling the frequency doesn’t necessarily improve security, especially in a static environment. However, with an increasingly rapid rate of change in service provider environments and the adoption of cloud and devops workflows, it’s likely that the reduction in time intervals is a broad risk management decision by the PCI SSC. Also, since many organizations outsource their penetration testing, don’t forget to add additional security budget for the service.

Requirement 11.3.4.1

Additional requirement for 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.

The next requirement looks to formalize the communication chain from security teams to their executive management (most likely C-level or Board of Directors). This produces acknowledgement of responsibility and improves awareness of current security practices around cardholder data. Do not hesitate to leverage this control to include details about the security of all sensitive data.

Requirement 12.4.1

Additional requirement for 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

The final two new requirements are purely managerial but can be beneficial. First, the process helps identify gaps in security operational procedures earlier. This allows a shorter window for potential vulnerability and provides time to pull the environment back into compliance. Secondly, it allows for the collection of evidence showing consistency and thoroughness in the management of compliance throughout the year. While the PCI Assessment is a snapshot in time (for the most part), showing ongoing adherence gives most QSAs “warm and fuzzies” and minimizes concerns about true compliance.

Requirement 12.11

Additional requirement for service providers only: 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

Requirement 12.11.1

Additional requirement for service providers only: 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

Appendix A2

Finally, do not forget about Appendix A2 buried down on page 119 of the DSS. Next year is the end of the road for grandfathered use of SSL and early TLS. As of June 30, 2018, the Risk Mitigation and Migration Plan is no longer sufficient and only secure versions of TLS should be in use. There is one small exception: POS POI terminals proven to not be vulnerable to known exploits. As service providers were required to meet this change by June 30, 2016 and secure protocols are available, there’s no expectation that this will be pushed out any further.

Conclusion

Only one of the new requirements (MFA for non-console admin access) may require architecture changes and/or capital expenditures. Additional penetration testing may also require budget outlay. The rest of the new requirements will need you to flex your governance muscles. Implementation of processes and procedures consume more time than most organizations expect.

Kudos if you already started working towards implementing these new controls, the finish line is approaching. If you are the kid who preferred to do something fun (or more likely, something more immediately necessary for your org’s security), there is still time left to make sure that you are ready for February 2018. It’s time to do the homework!