PCI DSS V3.2 – Council outlines planned changes

PCI DSS V3.2 - Council outlines planned changes
0 Shares

The updated PCI DSS version 3.2 is scheduled to be released at the end of April, in our previous post entitled ‘Council announce PCI DSS V3.2 update’ we looked at what was potentially making an appearance in the update. In this follow-up article, we examine the planned features to the new update that were presented by the Council in a QSA focused webinar, we also examine the key timelines.

 

Though there may be further changes or tweaks to the new update, our guide below should be a strong indicator of what is to come.

 

Multi Factor authentication for all administrative access to the CDE

One the main changes that was discussed by the council and largely reflects the evolving threat landscape; two factor authentication (TFA). TFA will be required for all admin access to the cardholder data environment. Where previously this was only required by individuals accessing via remote access, in future it will be a requirement for all – even from within the company’s own network.

 

This highlights the PCI SSC’s perceived weakness of only using a password, even via internal administrative console access.

 

Additionally from a terminology perspective, ‘two-factor’ authentication will change to ‘multi-factor’ authentication (MFA). To clarify this means that two or more of the three below items are required:

 

  • Something you are (Fingerprint and other biometrics)
  • Something you know (username, password, etc.)
  • Something you have (getting a code from your phone)

 

Updated SSL/early TLS encryption migration dates

The Council also highlighted in the webinar that the update will include an extension on the migration date for organisations to move from SSL encryption and early TLS (v1.0) to  TLS version 1.1 at a minimum. Ideally TLS version 1.2 should ideally be used due to known vulnerabilities with weaker ciphers and cipher suites.

 

The original date of June 2016 has now been moved to June 2018, however for service providers this does not apply and they must meet the June 2016 deadline.

 

Another item surrounding this subject is how PCI Approved Scanning Vendors (ASVs) deal with SSL and early TLS issues when undertaking ASV network scans.

 

If an ASV encounters SSL or early TLS vulnerabilities, the ASV must either obtain the client’s Risk Mitigation and Migration Plan (RMMP) or a letter from the client confirming that SSL or early TLS is not used – the ASV does not need to evaluate the RMMP, only to ensure the RMMP or the letter has been received to provide the exception to the PCI ASV failure.

 

If the client is being audited by a PCI QSA, this will be reviewed by the QSA.

 

If the Council decides to go ahead with the extension in the final version of the update, here at Sysnet we would strongly suggest that organisations adhere to the original date to ensure that they are not vulnerable to exploitation, and use TLS version 1.2.

 

Webpage URL

Find out more about our PCI DSS compliance services by clicking the button below

LEARN MORE

PCI DESV incorporation into PCI DSS

The PCI DSS Designated Entities Supplemental Validation (DESV) was a PCI DSS document that appeared in June 2015 and was aimed at entities that a payment brand or acquirer required additional validation due to;

 

  • storing, processing, or transmitting large volumes of cardholder data
  • providing aggregation points for cardholder data
  • suffering repeated or significant data breaches of cardholder data. This has now been incorporated into appendix A of PCI DSS v3.2.

 

Primary account masking

Currently, when displaying a payment account number (PAN) of a payment card, the maximum amount of numbers that are allowed to be displayed are the first six and the last four numbers. Due to forthcoming changes (ISO 7812-1:2015), the Issuer Identification Number (IIN) will increase from 6 digits to 8 digits.

 

The PCI SSC will now allow the PAN to be more than the original first 6 and last 4 digits in this situation.

 

Additional testing requirements in v3.2

Periodic testing requirements will be added to ensure all change control policies, standards, and procedures are in place and operating and designed. There may be more similar business-as-usual requirements added to PCI DSS v3.2.

 

Additional service provider requirements

In future service providers will be required to provide;

  • Cryptographic architecture documentation
  • Every six months – Penetration testing to confirm segmentation
  • Critical security control – systems detection/reporting
  • A formal PCI compliance program,
  • Quarterly confirmation – all security policies including standards and procedures are being followed by personnel. Incorporating Designated Entities Supplemental Validation into PCI DSS.

 

In addition, service providers may be required to provide extra validation. Aside from full PCI DSS validation, certain businesses and organisations (established by acquirers and payment brands) will be required to demonstrate some additional validation that determines whether a business’s day-to-day practices are reflective of their compliance.

 

In relation to the PA-DSS standard, there will be few changes. The changes that will take place will be largely to align it to PCI DSS v3.2.

 

With less than a month to go to the final release of the updated standard, the above list of changes may still be altered or expanded on, however it does give an insight to what is coming. The Council have shared the timeline of the key features and the dates for the transition to PCI DSS V 3.2:

 

PCI timeline

April 2016

  • PCI DSS 3.2 is scheduled for publication at the end of April. Publication will include a summary of changes document and webinar that provides an overview of 3.2 and the timeline and resources for putting it into place.
  • PCI DSS 3.2 supporting documents including Self-Assessment Questionnaires (SAQ), Attestation of Compliance (AOC) forms, Report on Compliance (ROC) templates, Frequently Asked Questions (FAQ) and Glossary will also be available at the end of the month.

 

 

May 2016

  • PA-DSS 3.2 will be published at the end of the May. The changes in PA-DSS 3.2 align with the changes made in PCI DSS 3.2. Information will be provided to PA-DSS application vendors and assessors on how this update impacts their programs.
  • PA-DSS 3.2 supporting documents including Report on Validation (ROV) and Attestation of Validation (AOV) forms, as well as Frequently Asked Questions (FAQ) will also be available at the end of the month.
  • A transition period will be provided to support completion of PA-DSS 3.1 validations already in progress.

 

 

October 2016

  • PCI DSS 3.1 will retire six months after the release of PCI DSS 3.2, and at this time all assessments will need to use version 3.2.

 

 

February 2018

  • The new requirements introduced in PCI DSS will be considered best practices until 31 January 2018. Starting 1 February 2018 they are effective as requirements.

 

Like this Article?

Subscribe to receive more tips & news about Cyber Security, Compliance and a lot more!

  • Sysnet Global Solutions will use the information you provide on this form to be in touch with you regarding non-promotional as well as promotional material by email and phone. If you agree to same, then please select the ‘I consent’ box after reading the terms and conditions listed below in relation to consent. You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, update your preferences for communications, content etc. by clicking on the update my preferences button in any email we send you or by contacting us at marketing@sysnetgs.com We will treat your information with respect. For more information about our privacy practices please visit our website. By clicking below, you agree that we may process your information in accordance with these terms. We use Pardot as our marketing automation platform. By clicking below to submit this form, you acknowledge or agree that the information you provide will be transferred to Pardot for processing in accordance with their Privacy Policy and Terms