Theft of information is a risk that will devastate any business without the proper security protocols in place. Companies that handle sensitive information, such as storing names and numbers for customers’ credit cards, are required to adhere to strict standards over the transmission and storage of that information. The Payment Card Industry Data Security Standard was most recently upgraded to version 3.2 in April 2016. Assessments performed after October 31, 2016 will need to use the updated PCI DSS 3.2. The new requirements under PCI DSS will be considered best practices until January 31, 2018; at which time it will become the required standard. This upgrade brought about a few important revisions for payment data storage service providers, including multi-factor authentication, designate entities supplemental validation and additional service provider requirements.
The greatest change coming with the upgrade to PCI DSS 3.2 is multi-factor authentication requirements. In the past, the requirement for multi-factor authentication only applied to a user with remote access to any credit card information database. The addition to PCI DSS 3.2 requires any user accessing credit card information to have two or more authentication steps, regardless of whether it is remote access or within the organization’s internal network.
There are a few different types of factors that businesses can use to validate access to the information database. These are generally broken down into something you know (a password), have (ID card) or are (fingerprint). Passwords, pin numbers, tokens, smart cards, fingerprints and other biometric authentication are all possible factor examples. Organizations can better adapt to this change by evaluating current authentication practices to see which areas are most likely to be affected.
Designated Entities Supplemental Validation (DESV)
A Designated entity is defined as any Acquirer or Payment Brand that requires additional validation exceeding the current PCI requirements. The DESV was created to assist organizations in ensuring there is a process to assess and document how they are continually compliant with PCI requirements. The DESV content is typically additional procedures that will be performed in conjunction with a standard PCI audit. The implementation of the DESV acts more as a reinforcement of the importance of monitoring security measures. There were already DESV requirements in previous versions of the PCI DSS, but the updated version will require more regular testing and analysis of current security measures if requested by a payment brand.
While the DESV is not an absolute requirement, there is a strong recommendation that payment card information holders assess their security measures and take action against any weaknesses or vulnerabilities on a more regular basis.
Service Provider Requirements
PCI DSS 3.2 also takes into account security measures that service providers should already have in place and makes them into hard requirements. Because these are actions that the service providers should already be using, it should not necessarily have a huge impact on current operations. These requirements include establishing responsibility for data protection, reporting failures in security control and maintaining documentation of cryptographic systems architecture and how it applies to the PCI related data in the organization’s environment.
Regarding SSL and TLS Migration
In early 2015 with the upgrade to PCI DSS 3.1, it was announced that Secure Sockets Layer (SSL) and early Transport Layer Security (TLS) were no longer secure options of storing sensitive information. The vulnerabilities are grave enough that the PCI Security Standards Council has mandated a migration from SSL and early TLS to a secure version of TLS. This migration date was originally set for June 30, 2016. However, in December of 2015, this date was pushed back. The current requirement states that processing and third-party entities must offer services involving TLS 1.1 or higher by June 2016 and completely cut over to a secure version of TLS by June 2018. This information was not changed in the upgrade to PCI DSS 3.2.
What Can Your Organization Do?
The upgrade to PCI DSS 3.2 is not likely to cause a massive overhaul of service providers’ current security measures. The best things any organization can do is to evaluate current protocols, take note of vulnerable areas and take action to make those areas in line with current security standards. For more information on security assessment, contact Barr Assurance & Advisory, Inc.