PCI DSS 3.2 marks a new incremental approach to updating security
With publication of the new PCI DSS 3.2 standard by the Payment Card Industry Security Standards Council (PCI SSC) due at the end of April, it’s well worth considering the changes, which are relatively minor, and establishing the likely impact of the new security measures on Merchants.
If we have a look at the recent history and look forward to the date where PCI DSS 3.2 becomes the compliance standard, we establish a timeline that looks like this:
- Feb 2015 – NIST highlights dangers of SSL/TLS1.0 or lower
- April 2015 – Security Council published 3.0 to 3.1
- Gave the industry until July 2016 to migrate away from SSL, TLS1.0 or lower
- However, market feedback concluded this timeline was too aggressive
- Dec 2015 – extended deadline to migrate from SSL/TLS1.0
- The Security Council extended the deadline of SSL/TLS 1.0 migrations until 2018
- April 2016 – PCI DSS 3.2 due to be published
- Oct 2016 – PCI DSS 3.1 retirement date, six months after the release of PCI DSS 3.2
- PCI DSS will be considered best practices until 31 January 2018
- Feb 2018 – from 1 February 2018 PCI DSS 3.2 becomes a requirement
- Moves from best practices to requirement
Up until now, PCI DSS annual updates have not reflected the unpredictable nature of cyber attacks. Breaches in security don’t happen to a timetable that fits with the Security Council’s major releases of the standard which is every November.
Troy Leach CTO of the PCI SSC recently stated the Security Council recognise they need to modify the standard by making more frequent incremental updates to address the constant threat of the landscape instead of wholesale update to the standard.
With this, the PCI SSC now acknowledges the end of the era of wholesale version updates and major releases. Subsequently, PCI DSS 3.2 is destined to be part of a program of more frequent incremental updates to align PCI with changes in security practice in a more timely fashion to reflect the emergence of real world threats as and when required.
With PCI DSS 3.2 the PCI SSC is perhaps looking to draw a line under the criticism associated with the December 2015 U-Turn where it changed the deadline date for upgrading SSL/TLS1.0 from June 2016 was to June 2018.
PCI DSS 3.2 key changes and impacts
There are a key number of minor changes enshrined within PCI DSS 3.2.
1. Multi-factor authentication
Multi-factor is something you have, own and are. It is often referred to as 2 factor authentication or 2FA. It is embedded in previous versions of the standard for remote access. In version 3.2 the scope has been extended to include local administrator access.
2. Designated Entities Supplemental Validation (DESV)
The Designated Entities Supplemental Validation (DESV) is a set of criteria designed to help service providers and others meet the inherent challenges of maintaining the appropriate security for protecting payments. This reinforces the importance and brings together various requirements to drive the ongoing process of security. Essentially, DESV enables acquiring banks or Visa brands to request more validation of authentication mechanisms from service providers.
3. PAN number masking
Masking Primary Account Numbers (PAN) is a requirement of PCI DSS. PCI DSS 3.1, Requirement 3.4 requires it be made unreadable and unrecoverable. PCI DSS 3.2 is set to clarify the masking criteria for primary account numbers (PAN) when displayed.
4. Migration dates for upgrading from SSL/TLS1.0 or lower
PCI DSS 3.2 updates the information on migration dates for SSL/TLS 1.0 and lower that were published in December 2015. The new deadline is now Jan 2018.
5. Self-Assessment Questionnaire – SAQ
The completion of the Self-Assessment Questionnaire (SAQ) by Merchant levels 2, 3 and 4 is required of companies handling transaction volumes of less than 6 million per year. It’s often a detailed and time consuming process.
Changes to SAQs under PCI DSS 3.2 mean that some of the 3.2 Self-Assessment Questionnaires will have more requirements than 3.1 while others will have fewer requirements. This is set to introduce more checks and balances; however the impact on Merchants is intended to be minimal.
How Merchants can prepare for PCI DSS 3.2
To help you prepare here are some things it is worth considering if you are in scope of PCI DSS 3.2:
- SSL/TLS migration planning is crucial
- Jan 2018 seems a long way off but for some businesses there is a lot that needs to be done. Understand how the migration is going to be implemented. SSL/TLS migration is an intrinsic element of version 3.1, so having it in place is a good place to start.
- DESV and what to expect from service providers
- Understanding your Service Provider’s controls that are in place around DESV and what they are they willing to change is very important. If acquiring banks and Visa brands wish the Service Provider to do things on behalf of your company then the SP has to be prepared and willing to do them.
- Multi–factor authentication
- Consider how multi-factor authentication is currently deployed. What’s in place at the moment and how is it accessed? Find out if this element of the system architecture can be adapted for internal network access as well as remote.
- Budget for changes
- Of course it is essential to budget for the changes. Putting the correct financial plan in place prevents unwelcome surprises for the finance department! Make sure to include all resource, planning and hardware costs such as any multi-factor authentication cards or fobs.
- Keep on top of the SSC published information
- Payment Card Industry Security Standards Council publishes summaries of changes at the end of April. Read the SSC literature when published and work alongside your Service Provider on changes required to update from 3.1 to 3.2.
By way of reassurance, the SSC has said that it anticipates no further changes such as the annual update that was historically released in November, unless security considerations create the need for additional incremental updates.