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 ...
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.
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).
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).
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.
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.
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).
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).
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).
A: We expect that the bulk of the DESV requirements will remain in Appendix A3.
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)
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.
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.
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.
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.
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.
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)
A: That much won't change.