Are You Ready For Some PCI DSS v3.2?

April 4, 2016 Eric Sampson

Coming in April 2016, the PCI Security Standards Council (SSC) is releasing an incremental update to the PCI DSS in version 3.2.  As an incremental update, there are minor changes to the PCI DSS requirements but some of the changes are significant.  To the community who implement the PCI DSS, here’s what you need to know:

Multi-factor authentication

The PCI DSS will no longer use the term “two-factor authentication.”  Going forward it will be referred to as “multi-factor authentication.”  Remote access to the CDE will still require at least two factors of authentication from among something you know (like a password), something you have (like a token), or something you are (biometrics).  Attacks on user accounts are much more difficult with multiple factors, especially where passwords are involved.  The PCI SSC has been monitoring breach reports and the attack vector of passwords, particularly where connections originate from corporate and internal networks, and concluded that stronger authentication measures are necessary.

Applicatoin Security Testing and Validatoin Webinar

Therefore, in PCI DSS v3.2, multi-factor authentication will be required for all admin access to the CDE - and that means all admin access to system components in the CDE, regardless of whether the connection comes by remote access or from an internal network, such as the corporate network.  The effective date for implementing multi-factor authentication for admin access is February 1, 2018.

Penetration Testing

Penetration testing to validate the effectiveness of network segmentation where used to reduce the scope of the CDE will be required at least every six months for service providers.  The effective date for this requirement will be released with PCI DSS v3.2.  Additionally, service providers only will be required to meet the following additional requirements:

  • Document the cryptographic architecture
  • Detect and report on failures of critical security control systems
  • Establish a formal PCI DSS compliance program
  • Confirm at least quarterly personnel are following security policies and procedures

SSL 3.0 / TLS 1.0

If you’ve been following recent updates from the SSC, you’re probably already aware that SSL and early TLS sunset dates have been published.  PCI DSS v3.2 will formalize the SSC’s announcements since December 2015 that SSL and early TLS may be permitted only as long as secure and preferred options, such as TLS 1.2 or higher, are made available by June 30, 2016, and a risk mitigation and migration plan is implemented with SSL and early TLS cut off dates no later than June 30, 2018.  The SSC emphasizes the importance of migrating away from SSL and early TLS as soon as possible, without delay.  The extension to June 30, 2018 should not be misinterpreted as an invitation to extend plans already made for implementation plans set by June 30, 2016.

TLS 1.1

TLS 1.1 implementations can be insecure.  The SSC recommends referring to published configuration guidance for TLS 1.1 implementations to ensure that insecure configurations are avoided.  For TLS 1.1 implementations, you should:

  • Disable weak ciphers/cipher suites (MD5, RC4, SHA-1, etc.)
  • Use sufficient key sizes
  • Prevent fallback to SSL and TLS 1.0
  • TLS 1.2 or higher recommended
  • See NIST SP 800-52 for guidance on secure TLS configurations
  • See FAQ 1373 for guidance on proper completion of the ROC or SAQ in relation to SSL and early TLS implementations.

The following supplemental guidance is recommended:

Designated Entity Supplemental Validation (DESV)

Designated Entity Supplemental Validation (DESV) requirements will be integrated into PCI DSS v3.2.  These are additional requirements for organizations deemed Designated Entities by their acquiring institutions or by a payment card brand.  Per the PCI SSC’s press release, the requirements “[are] designed to help companies address specific challenges in maintaining ongoing security efforts to protect payments.” Specifically, these additional requirements focus on maintaining PCI DSS compliance as a business-as-usual (BAU) activity, including regularly evaluating the effectiveness of the organization’s compliance program, scope, and efficacy of controls.  View the DESV requirements document.

Important Dates…

  • Sunset date for PCI DSS v3.1 will be October 2016 (6 months after 3.2 release)
  • PCI DSS v3.2 will be published April 2016
  • PA DSS v3.2 will be published in May 2016
  • Multi-factor authentication required by February 1, 2018

Audit Readiness

About the Author

Eric Sampson

Eric Sampson is a Manager at Schellman. Eric began his professional career in 2005 while working as an IT auditor in Philadelphia. Eric executed several critical projects for clients in the areas of information security and Service Organization Controls (SOC) reporting projects. To date, Eric has provided services to clients in the healthcare, information technology, and financial services industries, among others.

More Content by Eric Sampson
Previous Article
PCI DSS 3.1: 442 Days to Remove SSL 3.0 and Other Updates
PCI DSS 3.1: 442 Days to Remove SSL 3.0 and Other Updates

Today, the PCI SSC released version 3.1 of PCI DSS. The headline objective of 3.1 is to address weaknesses ...

Next Article
PCI SSC 2013 Community Meeting Takeaways
PCI SSC 2013 Community Meeting Takeaways

Via: InfoQ