If you missed it, do not feel bad. I too had to be told by friends and colleagues that the PCI SSC was having a Webinar on Thursday, March 31, to discuss the upcoming changes to the PCI DSS and PA-DSS as well as changes to other areas as a result. Apparently the Webinar was announced in the March issue of the QSA newsletter.
To begin their presentation, the Council made a big deal out of explaining why they are dumping the three year update cycle. The bottom line about this is that they feel the PCI DSS and PA-DSS are mature and therefore any future updates will be evolutionary not revolutionary as they have been in the past. As a result, we can expect more minor changes more often. Much like when the PCI DSS started out and we quickly got v1.1 followed by v1.2.
PCI DSS v3.2
The real piece of news here was that two-factor authentication (TFA) is going to be required for all administrative access to the cardholder data environment (CDE) regardless of whether that access is from the internal network or a remote network. I am sure this is in response to the number of breaches that involved administrators being spear phished.
Speaking of TFA, the Council indicated that they are going to switch terminology from “two-factor” authentication to “multi-factor” authentication (MFA). However, they were very clear when they discussed this change in terminology that they still mean the three factor model of something you know, something you have, and something you are. Their rationale on this change is to align the DSS with industry terminology. In the Q&A they got a lot of questions on this change as most security professionals said that clients would view MFA as including two sets of credentials versus TFA which has truly different factors. So we will see if the MFA decision stands when the new standard is released.
In addition, the Council outlined some other key changes we can expect to see in the latest version of the DSS. These are:
- Two new Appendices are being added to the PCI DSS. The first of which discusses the SSL/early TLS issues. The second is the incorporation of the Designated Entities Supplemental Validation (DESV) requirements into the DSS.
- Allowing the display of the PAN to be more than just the first six digits and the last four digits to align the PCI DSS with the coming changes to ISO 7812 which will increase the issuer identification number (IIN) from six digits to eight digits.
- Adding a number of additional requirements for service providers including: documentation of cryptographic architecture, detection/reporting on critical security control systems, penetration testing to confirm segmentation every six months, establishment of a formal PCI compliance program, and quarterly confirmation that personnel are following all security policies, standards and procedures.
- Periodic testing that all change control policies, standards and procedures are in place and operating as designed. This is the first of many business as usual (BAU) requirements that will be added to the PCI DSS.
More On SSL/Early TLS
The Council gave a bit more information regarding why they extended the deadline on SSL and early TLS out to June 30, 2018. As no surprise, the reason for the extension was push back from a variety of sources that found the 2016 deadline too short to convert.
I know from my own experience, I have a few clients that have contracts that do not allow them to make such changes without consultation with every customer impacted. In one case, it was going to take almost nine months just to consult with all of their impacted customers and then another seven months to implement the changes into production. In the perfect scenario, they would have cut over around September 2016, but they said past experience indicated a more likely date would have been July 2017 at the earliest.
The presenter reiterated that service providers must meet the June 30, 2016 deadline.
Also discussed was how ASVs are supposed to deal with SSL and early TLS issues. Until June 30, 2016, if an ASV encounters SSL or early TLS vulnerabilities, the ASV must obtain the mitigation plan or a letter from their customer attesting that a mitigation plan has been developed and the date when the customer will have addressed the vulnerabilities related to SSL and/or early TLS. The ASV does not need to assess the mitigation plan as the assessment of the mitigation plan is something the organization’s QSA must perform as part of the assessment process.
The final key point on this topic that the Council could not stress enough was, just because the deadline has been pushed out was no justification for an organization to wait until the last minute before addressing these critical vulnerabilities. If an organization can meet the June 30, 2016 deadline, then they should meet that deadline. If they need until December 31, 2016 to convert, then they need to mitigate the risk until December 31, 2016 when they can drop SSL and early TLS. But waiting for the sake of waiting because the deadline is in 2018 is unacceptable and needs to be called out as ‘Not In Place’ by QSAs.
Related to this discussion was the fact that vulnerability management still needed to be addressed through the mitigation. So if new vulnerabilities to SSL and/or early TLS are discovered while the organization is remediating their implementations of SSL/early TLS, the organization must still comply with requirements 6.2 and 11.2.
PA-DSS v3.2
No news is good news here. There will be little change to the PA-DSS standard other than to align it with PCI DSS v3.2.
However two significant changes are coming to an application’s Implementation Guide (IG).
The IG will now be required to address debugging logs that contain PAN data. Those debugging logs will be required to be protected, debugging will need to be immediately disabled once it is no longer needed and the debugging log data must be securely deleted as soon as it is no longer needed.
The IG will also be required to discuss the secure implementation of patches and updates to the application.
PA-DSS v3.1 dealt with the SSL/early TLS issue, so the Council felt that there would be no changes regarding that topic. That said, they did address the question as to whether or not TLS v1.1 is considered secure and laid out how TLS v1.1 needed to be configured to be secure. That configuration included:
- Disable weak ciphers and cipher suites such as MD5, SHA-1 and RC4.
- Use sufficient key sizes.
- Prevent fallback to SSL or TLS v1.0.
AQM Update
The Council indicated that the PCI DSS v3.2 and the Report On Compliance (ROC) reporting templates will be released simultaneously for the first time. Timing for these documents will be late April 2016. No specific date was provided.
On the PA-DSS side, the Council stated that the v3.2 Report On Validation (ROV) reporting template and the standard will be released in May 2016. Again, no specific date was provided.
Cutover to v3.2 for both standards was discussed with the PCI DSS cutover being the more specific. PCI DSS v3.2 will go active upon release with sun setting of v3.1 occurring in October 2016 on whatever day matches the release date. Cutover and sun setting on PA-DSS will be announced with the release of the v3.2 standard. Use of both standards and reporting templates can occur immediately but we were reminded that everyone must cutover by the relevant sunset dates.
The Council also indicated that any relevant v3 FAQs will also be updated when the new standards are released.
ROC/ROV Personalization
The final point discussed under the AQM banner was the personalization of the ROC and ROV reporting templates by QSACs and PA-QSACs. According to the presenter, the Council is hearing complaints from banks and the brands about the “over personalization” of ROC and ROV reports.
The Council stated that they understood the desire of QSACs and PA-QSACs to put their logos on the reports as well as making other “minor” changes to make the reports reflective of their organization. However, banks and the card brands have been complaining that some of the personalization done had made the reports different enough from the original templates as to make them difficult to quickly review and process.
As a result, the Council has felt it necessary to issue guidelines on what personalization of the ROC and ROV templates is allowed. Under these new guidelines:
- Adding a title page to the report templates is allowed.
- Adding a company’s logo to the report header is allowed.
- No changes are allowed to any of the reports footers.
If you did miss this Webinar, the Council stated they were recording the session and it will be available on their PCI Portal sometime in the next few days.
