Best Practices No More: What You Need to Know About the Upcoming PCI DSS 3.2 Requirements

February will bring Groundhog Day, Valentine's Day, the return of the Year of the Dog in the Chinese calendar and another important deadline for your compliance with the Payment Card Industry Data Security Standard (PCI DSS).

On Feb. 1, version 3.2 best practices transition to full requirements. These controls must be in place by that date and not deferred until the time of your annual assessment.

These best practices are indeed practices that every organization should implement as soon as possible. Ideally you already have your plans underway, and here is some information that will help you along.

General Best Practices Transitioning

Best practices for merchants that are becoming requirements are: 

  • Requirement 6.4.6: All relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated accordingly. This is designed to ensure that security controls are in place following changes to the cardholder data environment (CDE), and that proper change management procedures are being followed, including maintaining accurate diagrams and inventory of the CDE. 
  •  
  • Requirement 8.3.1: Administrative access to the CDE, whether administrative access to infrastructure, database or application, requires a minimum of two separate forms of authentication (such as a password, a smart card or a fingerprint) before access to the CDE is granted. This extra layer of authentication, known as multi-factor authentication means that a password alone is not enough and provides additional assurance that the individual attempting to gain access to the CDE is who they claim to be. With multi-factor authentication, an attacker would need to compromise at least two different authentication mechanisms, which increases the difficulty of compromise and thus reduces the risk.

The PCI Security Standards Council (SSC), which manages the standard, offers a supplement called Guidance for Multi-Factor Authentication (PDF)   

The SSC notes that while it does not currently require multi-factor implementations to meet all the principles described in this guidance document, it may in the future, and these industry-recognized best practices provide a roadmap for future security considerations.

Service Providers are a Focus 

Merchants should also make sure that their service providers are adhering to these new requirements.

Seven best practice sub-requirements for service providers take effect on Feb. 1:

  • Requirement 3.5.1 necessitates a documented description of the cryptographic architecture that includes details of all algorithms, protocols, and keys used for the protection of cardholder data.
      
  • Requirement 10.8 necessitates implementation of a process for the timely detection and reporting of failures of critical security control systems. This includes documentation of the process for this control, identification of the personnel responsible for implementing this control, and the associated alerting processes and procedures.
      
  • Requirement 10.8.1 necessitates timely response to failures of any critical security controls, with the SSC list of possible security controls including firewalls, file integrity monitoring (FIM), anti-virus and audit logging such as SEIM. It specifies processes for responding to failures in security controls, including identifying and documenting the cause and duration of the security failure, performing a risk assessment to identify further required actions, implementation of additional security controls, and restoration of security functions and monitoring.
     
  • Requirement 11.3.4.1 necessitates penetration testing on segmentation controls at least every six months. This means that, as of Feb. 1, service providers must have a process in place to perform penetration tests of their segmentation controls at least every six months with the first required by Feb. 1. By Aug. 1, 2018 you should be able to demonstrate two segmentation tests in the most recent year.
  •  
  • Requirement 12.4.1 necessitates overall accountability for maintaining PCI DSS compliance, and the definition of a charter for a PCI DSS compliance program and communication to executive management, as well as defining how the PCI DSS compliance program is organized and communicated to executive management. 
  •  
  • Requirement 12.11 necessitates quarterly reviews to confirm personnel are following specified security policies and operational procedures. This reinforces the SSC's mandate to make compliance a business-as-usual practice, and focuses on ensuring that the periodic activities throughout the year are being done (i.e. daily log reviews, firewall rule-set reviews, application of configuration standards to new systems, responding to security alerts and following the proper change management process). 
  •  
  • Requirement 12.11.1 necessitates documentation of the quarterly review process, as well as ensuring that documentation demonstrating that these reviews are being performed is being done and retained.

You Should Be Well Along Your Migration Path from SSL/Early TLS

And while PCI DSS 3.2 explicitly extended the deadline for migration from SSL and early TLS to June 30, 2018, you should already have your formal risk mitigation plan in place and be working quickly to get away from these insecure protocols. As stated in the 2017 Trustwave Global Security Report, for the second year in a row, four of the top five vulnerabilities that our network scanning systems detected resulted from insecure server configurations for Secure Socket Layer (SSL) and Transport Layer Security (TLS).

Scan the Horizon for Emerging Best Practices and Talk to Your QSA-C!

Remember, as our Trustwave Qualified Security Assessor (QSA) experts always say, the PCI DSS is a baseline standard - the minimum set of requirements that you should be addressing for the security of your business and your payment card data. Compliance should be a byproduct of a robust security program. Implementing sound security controls, rather than just focusing on just being compliant is the best way to make sure that you are properly addressing the ever-changing threat landscape.

Beyond meeting the PCI DSS 3.2 requirements that go in to effect in February, engage in proactive discussions with your QSA company (QSA-C) about additional security best practices your organization should be considering. These best practices may even be on the horizon for the next update to the PCI DSS.

Dixie Fisher is senior product manager of compliance solutions at Trustwave.

Trustwave reserves the right to review all comments in the discussion below. Please note that for security and other reasons, we may not approve comments containing links.