PCI DSS 3.1 is the answer to flaws in SSL and early versions of TLS.

The PCI Council has been officially planning the launch PCI DSS version 3.1 since mid-February and two months later, it is finally ready for use.

When was the new version published?

PCI SSC general manager Stephen W. Orfei recently said:

"We are focused on providing the strongest standards and resources to help merchants and their business partners protect against the latest threats to payment data. The PCI Standards development process allows us to do this based on industry and market input,"

and he also explained the goal of the revised standard

"With PCI DSS 3.1 and supporting guidance we are arming organizations with a pragmatic, risk-based approach to addressing the vulnerabilities within the SSL protocol that can put payment data at risk."

The PCI SSC officially published the new Requirements and Security Assessment procedures on the 15th April.

Why was there the need of a new release?

The main reason for this new release was the discovery of flaws in the SSL (Secure Sockets Layer, version 1, 2 and 3) and early versions of TLS (Transport Layer Security), which are used as strong cryptographic solutions to ensure the privacy and reliability of data transmitted over online channels, but revealed to provide a weak encryption.

We have discussed the reasons behind the release of the Data Security Standard into a new version in two previous blog posts:

• Be prepared, PA DSS and PCI DSS version 3.1 are going to be out soon
• PCI DSS 3.1 is moving fast. How are requirements going to change?

When will PCI DSS 3.1 go into effect?

The PCI SSC says:

"The Lifecycle for Changes to PCI DSS ensures a gradual, phased introduction of new versions of the standard in order to prevent organizations from becoming non-compliant when changes are published."

And further,

"During the lifecycle, the Council will continuously evaluate evolving technology and threats, and if necessary, make mid-lifecycle changes to the standards or provide ongoing supplemental guidance about these issues."

Looking at the official communication from the Council, we can understand more about several important steps that both security experts and organizations should be aware of:

• When it comes to existing implementations, SSL and early versions of TLS are no longer considered secure and they will have to be replaced. Organizations have until the end of June, 2016 to do so.
• In the meantime, a risk mitigation plan must be in place for those organizations that continue to use those encryption methodologies. Supporting guidance is available here.
• Regarding new implementations, SSL and early versions of TLS are no longer accepted.
• Devices used to make a purchase like POS (Point-of-sale) or POI (Point-of-interaction) that are "not susceptible to all known exploits for SSL and early TLS, may continue using these protocols as a security control after 30 June 2016."

The updates brought by PCI DSS version 3.1 in a nutshell.

A bit of terminology before getting started: PCI DSS 3.1 contains 4 evolving requirements, 4 areas of additional guidance and 30 clarifications.

• Clarification: Clarifies intent of requirement. Ensures that concise wording in the standard portrays the desired intent of requirements.
• Additional guidance: Explanation, definition and/or instruction to increase understanding or provide further information or guidance on a particular topic.
• Evolving Requirement: Changes to ensure that the standards are up to date with emerging threats and changes in the market.

Let's look at these changes a little closer

The 4 Evolving Requirements

Impacted requirements: 2.2.3, 2.3, 4.1, 4.1.1.
Content: All versions of SSL from this release are considered as examples of weak encryption.

The 4 Additional Guidance

Impacted requirements: 4.2, 11.2, 12.9, Appendix C.
Content: Clarified some aspects about end-user messaging (SMS), vulnerability scanning with automated and/or manual tool, involving service providers in specific requirements, use "sudo" rather than "su" command as compensating control.

30 Clarifications

Impacted requirements: 3, 4, 6, 8, 9, 10, 11, 12.

Requirement 3:

• Clarified in requirements that storage of Sensitive Authentication Data is not permitted "after authorization".
• Clarified in the requirement notes that additional controls are required if hashed and truncated versions of the same PAN are present in an environment. Added Testing Procedure 3.4.e to assist with validation of the requirement. Clarified intent of truncation in Guidance Column.
• Clarified that "HSM" may refer to a "Hardware" or "Host" Security Module. Aligned with language in PCI PTS.
• Clarified that Testing Procedure 3.6.a only applies if the entity being assessed is a Service Provider.

Requirement 4:

• Included SMS as an example of end-user messaging technology and added guidance.

Requirement 6:

• Added clarification to the testing procedure and guidance that if an automated technical solution is configured to alert (rather than block) web-based attacks, there must also be a process to ensure timely response.

Requirement 8:

• Clarified that inactive user accounts must be removed/disabled within 90 days.
• Clarified that the testing procedure only applies if the entity being assessed is a Service Provider, and for non-consumer customer accounts.
• Clarified that passwords must be changed at least once every 90 days.
• Clarified this requirement only applies if the entity being assessed is a service provider.

Requirement 9:

• Clarified that the requirement applies to all onsite personnel and visitors.
• Combined Testing Procedures 9.2.b and 9.2.d to remove redundancy.
• Updated the testing procedure to clarify both devices and device locations need to be observed.

Requirement 10:

• Removed redundant language in guidance column.
• Updated requirement to more clearly differentiate intent from Requirement 10.6.2.

Requirement 11:

• Clarified that testing procedure applies where wireless scanning is utilized.
• Removed redundant language from testing procedure.
• Clarified that the intent of the penetration testing is to verify that all out-of-scope systems are segmented (isolated) from systems "in the CDE" (Cardholder Data Environment).
• Clarified that unauthorized modifications include changes, additions, and deletions of critical system files, etc.

Requirement 12:

• Clarified that the risk assessment process must result in a formal and "documented analysis of risk".
• Clarified this requirement only applies if the entity being assessed is a service provider and added related guidance.

Furthermore, there are some other minor changes to report:

• Changed reference from "protecting cardholder data" to "protecting account data".
• Changed reference from "financial institutions" to "acquirers, issuers".
• Clarified that validation processes for Service Providers include undergoing their own annual assessments or undergoing multiple on-demand assessments.
• Reordered assessment steps to clarify that a ROC, SAQ, or AOC may be submitted without all requirements being "in place".
• Addressed minor typographical errors (grammar, punctuation, formatting, etc.) and incorporated minor updates for readability throughout the document.

Make sure to comply with the PCI DSS version 3.1.

Advantio are PCI Compliance experts and can aid your company in achieving compliance.

As a trusted advisor, our QSAs (Quality Security Assessors) can support an organisation in understanding the requirements, verify eligibility and can help with the completion of any SAQ. We can guide your company on the path to compliance, supporting you every step of the way.

Understand the impact of the new version 3.1 on your business, achieve and maintain PCI DSS Compliance continually, keep your business safe and healthy by making sure that you retain your customer’s trust.