17 Predictions About the Next Version of PCI DSS

By David Gamey - 10 Jan 2018.

Tags:

blog
pci
x

PCI DSS v3.2 is due for an update this year - but what will that look like? In this article, we peer into our crystal ball to make some predictions ...

What Will The New DSS Bring?

Q: The updated DSS will need a new version number, so will that be: 4.0, 3.3, or 3.2.1?

A: The PCI Council indicated in 2017 that they expect that the next update to the DSS will not be a major overhaul. We've also seen indications that there will likely be changes that go beyond just baking in future dated requirements. We expect a new DSS published before the end of Q3 2018 and it will be version 3.3.

Q: What about SSL and early TLS?

A: The transition period ending June 30, 2018 will not be extended. The exemption for POI devices that can show they remain safe to use will remain for the foreseeable future. As PCI PTS and PA-DSS have not allowed this exemption for some time there may be clarification that this is intended for legacy devices (i.e. pre-existing deployments).

Q: What about Multi-factor Authentication requirements?

A: The current MFA requirements dated January 31, 2018 will be baked into the new DSS. This was supported by recently released guidance on MFA (see PCI below). So we don't expect major changes here. Some minor clarifications are possible and we wouldn't be surprised to see FAQs emerge (e.g. strong vs. weak MFA).

Q: What about the other January 31, 2018 requirements?

A: The requirements to ensure that all entities include PCI DSS controls in all new or updated systems; as well as, the additional documentation and procedures required of service providers will be baked into the new version. Possibly these will be accompanied by some clarifications.

Q: How soon will the new DSS come into effect?

A: We expect that the new DSS will be designed to come into effect very quickly after publication. In order to facilitate this, we expect that any significant changes will be future dated to allow for orderly transition.

Q: How will PCI align with the new NIST password complexity guidance?

A: We would expect the new DSS will handle this in an evolutionary manner retaining backward compatibility and using "equivalent or better strength" interpretations. We'd like to see adjustments that wouldn't require the use of compensating controls (see NIST below).

Q: How will the DSS align with the updated OWASP 2017 top 10 list?

A: While OWASP and PCI don't always stay in perfect alignment, this generally should not be a problem as PCI is intended to align with current industry best practices (note on 6.5) and has a backstop rule (6.5.6). The back stop requirement mandates that "high severity" vulnerabilities must be corrected. However, there has been some recent drift which includes a couple of significant changes (see OWASP below). We expect there is a reasonable chance of PCI DSS clarifications and possibly some future-dated requirements to bring these closer together. The following have no direct correlation in (6.5.x) and we think that there may be some adjustment to better align with A4, A8, and A9. From a best practice perspective, it may be time to ensure that code reviews look for logging deficiencies (A10).

A4:2017 XML External Entities (XXE)
A8:2017 Insecure Deserialization
A9:2017 (and 2013) Using Components with Known Vulnerabilities
A10:2017 Insufficient Logging & Monitoring

Q: Will any of the requirements that apply only to service providers be applied to merchants?

A: Several Business as Usual (BAU) requirements, such as validating that executive management has established responsibility for an internal PCI DSS compliance program (12.4.1) and that processes are being followed throughout the year (12.11), may be considered for expansion to merchants. Again, we would expect these to be future dated and possibly with different frequency (e.g. semi-annually vs quarterly).

Q: Will any of the Designated Entity Supplemental Validation (DESV) requirements make it into the core of the DSS?

A: We expect that the bulk of the DESV requirements will remain in Appendix A3.

Q: How will the DSS address industry changes, such as the new 8-digit BINs?

A: The rules for truncation will remain the same; however, there may be clarifications added to account for the fact that in some cases full 8-digit BINs may be considered cardholder data requiring protection (e.g. encryption). See BIN truncation below)

Q: Will the new DSS deprecate 64-bit-block ciphers like 3-DES and Blowfish?

A: PCI tends to avoid specifying algorithms within the DSS and relies instead on the use of "strong cryptography" and the use of supporting documents. However, the problem with 64-bit-block is similar to the SSL and early TLS problem with a similar mix of use cases and migration challenges (see Sweet32 below). We anticipate that a solution similar to Appendix A2 and the SSL/early TLS migration with long future dates may be included in the next DSS.

Q: Will the new DSS deprecate SHA-1?

A: The DSS relies upon the definition of strong cryptography in the official PCI DSS Glossary and FAQs (see SHA-1 below and PCI FAQ). We expect this will be addressed within the Glossary.

Q: Will there be requirements for new security technologies like white-listing, code-signing, or Data Loss Prevention?

A: We don't anticipate the council will require the addition of new technologies into the DSS. They will continue to be used as examples in guidance and by organizations needing formal compensating controls.

Q: Will the DSS directly address newer technologies such as cloud and containers?

A: These are not generally addressed directly by the DSS but through separate guidance such as the 2013 Cloud guidance. At this time, there is no scheduled update for Cloud or Container technologies. If your organization is interested, you may want to contact the PCI Special Interest Group team.

Q: Will there be further clarifications to the e-commerce applicability scenarios used in SAQ A and A-EP and the supporting IFRAME/URL-redirection FAQs?

A: The current criteria for distinguishing these use cases continues to cause confusion in cases such as scripted IFRAMEs. While we don't expect the DSS to directly address this, we do expect that further clarifications in the form of FAQs are likely. While there is a potential for some future dated requirements such as confirming the same origin policy is in force, we expect that additional SAQ eligibility requirements, or increasing the compliance footprint used for the simplest redirection use cases are more likely.

Q: Will there be further changes to segmentation and isolation requirements/guidance?

A: We don't anticipate any major changes in the DSS requirements or current scoping guidance a around segmentation and isolation. While there is always the potential for clarifications or minor updates through FAQs, we view this as mature and stable. (see "Connected-to" below and Scoping below)

Q: Will PCI DSS continue to challenge organizations?

A: That much won't change.

Learn More