PCI compliance

PCI Compliance for Version 3.2: FAQs and To-do’s

Aug 03, 2016 By Paul Curran

As families all across America dress up and trickle into the streets for trick-or-treating on October 31st, 2016, there is one more ghost that will be vanishing into the chilly, autumn air at midnight: PCI DSS version 3.1.
Since the introduction of PCI DSS 3.2 in April 2016, organizations have been working hard to ensure that they’re compliant with these new standards put forth by Payment Card Industry Security Standards Council (PCI SSC).

 

What threats to the payment card industry prompted this incremental update and what new protections will version 3.2 contain?

PCI DSS Version 3.2
What is PCI DSS Compliance?

In order to create an additional layer of protection for card issuers, Visa, MasterCard, Amex, Discover and JCB had each created their own individual programs to guarantee that merchants were able to meet a certain level of security when handling and processing cardholder data. To align their policies and create one bigger governing body over security standards regarding credit cards, the five major credit card companies came together in 2004, and the PCI SSC, or Payment Card Industry Security Standards Council, was born.

 

Since launching, the PCI Data Security Standard groups their 12 compliance requirements into six groups known as “control objectives.”

 

PCI Compliance for Version 3.2 FAQs

 

What’s New in PCI DSS Version 3.2?

Version 3.2 of the PCI DSS is the 8th version released by PCI SSC and addresses the constantly evolving threats to the payment card industry. The version includes new sub-requirements which include the need to ensure that multi-factor authentication is used for all non-console administrative access and all remote access in the cardholder data environment.

 

Additionally, two new appendices have also been added which deal with migration deadlines for the removal of Secure Sockets Layer (SSL) /early Transport Layer Security (TLS) as well as “Designated Entities Supplemental Validation” (DESV) which was a separate document in previous versions.
According to the PCI SSC, the version changes for PCI 3.2 came as the combined result of changes that occur in the payment industry, data breach report findings as well as constant industry feedback from the PCI Council’s Participating Organizations which number over 700 globally. A complete list of the changes between version 3.1 and 3.2 can be viewed on the PCI SSC website here.

 

How Long do Organizations Have to Adapt to the New PCI DSS Standard?

Despite fact that PCI DSS version 3.2 was released in April 2016, merchants are able to make their transition from 3.1 to 3.2 until October 31, 2016. Once version 3.1 is no longer available, organizations are able to work on their transition without being fully compliant until February 1st, 2018 which is when this latest version will be enforced.

 

Until January 31, 2018, the changes that organizations need to adapt to for PCI DSS 3.2 will be considered as “best practices,” without being enforced, although businesses who are serious about protecting their data against exploits, hacks and theft should make the switch as soon as they can, given the rate that hackers and malicious parties are able to evolve and adapt their tactics when preying on the payment card industry.

 

Is there a Planned Update to the PA-DSS as well?

The PA-DSS, a global security standard also created by the Payment Card Industry Security Standards Council (PCI SSC), was initiated in order to provide the definitive data standard for software vendors that develop payment applications. The PA-DSS ensures that software vendors are developing applications that are compliant with the current PCI DSS standard while preventing third party payment applications from storing sensitive data such as CVV2, PINs or magnetic strips.

 

PA-DSS 3.2 was released on June 1, 2016 and PCI Security Standards Council Chief Technology Officer Troy Leach recommends that organizations familiarize themselves, with and adopt, the required changes from this version before the version 3.1 retires on August 31 2016.

 

The majority of changes made in PA-DSS version 3.2 are to align this standard with the improved standards found in PCI DSS version 3.2. Leach explains, “For example, PA-DSS Requirement 12.2 supports PCI DSS Requirement 8.3.1 for using multi-factor authentication (MFA) for non-console administrative access to the cardholder data environment. What this means from the PA-DSS perspective is that the vendor can choose to either include instruction about using MFA in the payment application’s Implementation Guide, or provide MFA functionality within the payment application itself.”

Dig deeper: read more about PA DSS version 3.2 here.

How to Become PCI DSS 3.2 Compliant

Among the changes organizations will need to make to become PCI compliant for version 3.2 is the new requirement 6.4.6. This requires organizations to ensure security controls are in place following a change in their cardholder data environment. Troy Leach explains that is it has become crucial to establish a process in which companies are able to analyze the ways in which changes may impact both the environment and security controls used by an organization in order to secure and protect sensitive user payment data.

PCI COMPLIANCE
Additionally, new requirements 10.8 and 10.8.1 mean that service providers to detect and report on failures of critical security control systems which will provide the organizations with formal processes to immediately identify and alert failures to critical security control to lessen the amount of time hackers are able to exploit payment and user information from within their systems.
Leach also explains how new requirement 11.3.4.1 increases the frequency of penetration testing on segmentation controls from annually to every six months in order to ensure that this will help organizations to ensure that the PCI DSS scope remains up to date and aligned with changing business objectives.
“This is one of the most important controls to assure the proper focus of PCI DSS controls.  With this change, we emphasize that importance with more frequency of testing to confirm security controls are in place and working.” – PCI Security Standards Council Chief Technology Officer Troy Leach

Dig deeper: Read the full list of changes your organization needs to make to be 3.2 compliant, and why, here.

How Does Checkmarx Help with Obtaining PCI DSS Compliance?

Checkmarx’s CxSAST static code analysis solution makes obtaining PCI DSS compliance much easier. While nothing will replace the PCI DSS audit process, implementing Checkmarx as a static code analysis solution helps address two PCI DSS requirements: developing and maintaining secure software and applications and regularly testing security systems and process, numbers 6 and 11 respectively on the requirements list.

 

PCI DSS Requirement 6: Develop and Maintain Secure Systems and Applications

Since malicious parties often target payment card data through exploits made possible through insecure coding practices, it’s critical that everyone involved in any stage of payment processing adopts, and enforces, secure coding practices. Requirement 6.1 calls for organizations to establish a process to identify security vulnerabilities which is an out of the box feature of Checkmarx as all vulnerabilities found during scans are categorized and assigned a severity level.
PCI DSS requirement 6.6 calls for public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

  • Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes.
  • Installing an automated technical solution that detects and prevents web-based attacks (for example, a web- application firewall) in front of public-facing web applications, to continually check all traffic.

Checkmarx CxSAST fully integrates within any payment card industry organization’s SDLC which will give them a constant analysis of code regardless of whether it’s new or previously written code.

 

jumping 1

 

To learn more about how Checkmarx can help your organization receive PCI DSS compliance, be sure to read: How to achieve PCI DSS Compliance with Checkmarx Source Code Analysis

The following two tabs change content below.

Paul Curran

Content Specialist at Checkmarx
With a background in mobile applications, Paul brings a passion for creativity reporting on application security trends, news and security issues facing developers, organizations and end users to Checkmarx's content.

Latest posts by Paul Curran (see all)

Stay Connected

Sign up today & never miss an update from the Checkmarx blog

Get a Checkmarx Free Demo Now

Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.

Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.