The Council Speaks About v3.2

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.


14 Responses to “The Council Speaks About v3.2”

  1. 1 Rob
    April 6, 2016 at 11:17 PM

    Is the webinar available for the public to view, for those that missed it?

  2. 3 Sam
    April 6, 2016 at 8:40 AM

    Thanks for keeping us informed! Regarding your statement:

    “The presenter reiterated that service providers must meet the June 30, 2016 deadline”

    Can you give me an idea of where this requirement is for service providers in the PCI DSS? I work for a service provider and we have been trying to get our customers to upgrade, but this has been very difficult since the council changed the allowed compliance dates… A vast majority of our customer base has done exactly what the council warned against and dropped efforts to migrate until 2018. This has put us in the difficult position of having to argue with our customers who think we are pre-maturely sunsetting the protocol.

    • April 7, 2016 at 6:17 AM

      The service provider ruling is not in the current version of the PCI DSS but is coming in the v3.2 release. That said, the original SSL/early TLS deadline was June 30, 2016 which is documented in v3.1 of the PCI DSS in requirement 4.1. That deadline was extended to June 30, 2018 back around the first of the year due to push back from a lot of organizations. What the Council is now saying is that service providers must abide by the original 2016 deadline. That said, I know a number of service providers that will not be able to meet the 2016 deadline due to legal obligations that supersede the PCI DSS requirements. The other thing in your favor is that the Council was also adamant on their Webinar that delaying because you can is NOT an approved reason to delay. QSAs were told on that Webinar that if we find that our clients are just waiting until the last minute to convert, then 4.1 is to be marked ‘Not In Place’ as that is not allowed.

      • 5 Sam
        April 29, 2016 at 11:36 AM

        Now that 3.2 has been released I am looking through the requirements for service providers and see the following:

        “All service providers must provide a secure service offering by June 30, 2016.”

        But this doesn’t appear to require that TLS1.0 is disabled… It seems to mean that newer/secure protocols must be offered and could be in addition to TLS1.0? Am I missing something in 3.2 that would indicate otherwise?

      • May 3, 2016 at 8:46 AM

        I think it’s just an issue with the Council thinking that their statements about “early TLS” clarified that TLS 1.0 was not allowed.

  3. 7 Louis
    April 1, 2016 at 1:01 PM

    Are we saying *all* of DESV will be incorporated and how exactly is that going to take place ?

    Can we do it on a risk based approach ?

    I vaguely remember Troy Leach saying (PCI Acquirer January 2016 conference) they would take parts of DESV.

    • April 1, 2016 at 2:38 PM

      All of the DESV will be included as an Appendix (Appendix A-3 I believe is what they said) in the PCI DSS.

      Not sure about your risk based approach question. The DESV portion will only need to be filled out if an organization is considered a “Designated Entity” by their bank or the card brands.

  4. 9 CR
    April 1, 2016 at 6:33 AM

    Thanks for the article, PCI Guru.

    “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.”

    Presumably, this doesn’t mean that an additional 2 digits of a 16-digit PAN can be displayed (i.e. 12345678xxxx1234), because this means there are then only 10,000 possible options to guess/hack/crack the real PAN (not the present 1,000,000 combinations).

    Rather, does it mean that if IIN increases to 8 digits, a 16-digit PAN would increase to 18 digits? And then there are still 10^6 combinations?

    • April 1, 2016 at 10:29 AM

      That is a question for the people working on the ISO 7812 changes as well as the card brands. In theory, the PAN is not limited to 16 digits as the ISO 7812 standard allows for up to 19 digits in total, the IIN which is now six digits, up to 12 digits of an account number and finally a check digit of one digit for a maximum total number of digits of 19. Under the proposed changes, I would expect that the account number portion of 12 digits would be reduced to 10 digits under the current scheme unless the standards body increases the length to 21 digits.

    • 11 Kyle
      April 2, 2016 at 7:50 PM

      It’s not 1,000,000 or 10,000 possibilities. Because the last 4 contains the check digit we can automatically throw away 90% of possibilities. Add in the fact that the the distribution of numbers does not appear to be random then some more heavy maths can throw away another couple %. A few months back some guy cracked whatever algorithm AmEx uses: http://www.wired.com/2015/11/samy-kamkar-10-dollar-tool-can-guess-and-steal-your-next-credit-card-number/

      I have no idea why storage of the check digit is allowed. It must be some hold over from the 60s where brute forcing numbers was too slow. If we’re finally going to see non-16 digit cards in the wild then they should change the format to something like 0000-0000-0000-0000-0

      • April 4, 2016 at 2:02 PM

        Surprise, surprise! Not every card number has a check digit at the end. As a number of my clients have found out, the card brands have abandoned the check digit particularly with gift cards and single use accounts (SUA). So you cannot guarantee that those digits will tie out to a last digit check digit.

        However, that still does not minimize the risk presented by reducing the number of middle digits not displayed on 15 and 16 total digit PANs. It just means the bad guys will have to work harder.

      • 13 Kyle
        April 5, 2016 at 10:35 AM

        But wouldn’t such cards have a detectable IIN and then you could choose to ignore them, especially since they’re likely to be low value accounts and are often restricted to a specific country as well?

        Realistically though even if there is only 100 combinations you’d get flagged on the network long before you tried them all out. It’s just funny that hash and crypto algorithms are retired when they lose 0.001% of effectiveness but the card companies are happy with a 90% drop in an area they have direct control over.

      • April 7, 2016 at 2:09 PM

        I have since heard that for the IIN to increase to eight digits, the PAN will have to increase to the maximum of 19 digits for security reasons. The 15/16 digit PANs will stay with on the six digit IIN.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

April 2016

%d bloggers like this: