In October 2013, the Payment Card Industry Security Standards Council (PCI SSC) released the final version of the most interesting standard for all merchants and service providers who work with credit cards, the Payment Card Industry Data Security Standard (PCI DSS). This standard is widely regarded as one of the information security industry’s most important baselines for ensuring the security of sensitive data.
The old version 2.0 will remain applicable till 31th December 2014 which provides companies the necessary amount of time to meet the requirements of the new version. From 1st January 2015, only version 3.0 will be valid.
PCI SSC works with the standard on a 3 years cycle. During the first year after the publishing of a new version vendors completes their implementation of the new standards but the previous version of the standard is still applicable. From
November of the first year to March of the second year PCI SSC collects feedback on the new version. At the end of the second year the old version of the standard is retired and all validation efforts for compliance must follow the new standard. During April through August of the second year the PCI SSC reviews feedback. In the spring of the third year the Council’s Technical Working Group prepares a draft version of the next version of the standard. The final point within the standard lifecycle is the approval of the final version (in July) and final publication (in October). You can find more detailed information on the official site.
So let`s begin to investigate the most interesting question: what is new within the newest version of PCI DSS?
Changes between versions 2.0 and 3.0
The new version has nearly a dozen new compliance requirements across all 12 parts of the standard. They contain not only clarification of old requirements but some innovations. The full list of changes you can also find in the official document provided the PCI SSC. I propose to focus on the most interesting points.
The one of the most significant changes within version 3.0 is connected with requirement 11.3. In addition to the old requirements, stating that a merchant should annually perform a penetration testing assessment, version 3.0 adds a new requirement: an organization that offers the penetration testing service should have a documented penetration testing methodology which “is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)”. Therefore, merchants must be very careful in their selection of a third-party provider to make sure that the processes followed by the selected vendor adhere to an industry-accepted methodology.
One positive moment is the new requirement will be mandatory only after July 1st, 2015.
Inventorying System Components
Next, requirement 2.4, which brings additional headaches to merchants, concerns inventorying of all system components that are in scope for PCI DSS. Within the standard, a component is usually understood as any hardware (virtual or physical hosts and network devices) or software (custom or commercial, off-the-shelf applications, etc.) within the cardholder data environment (CDE). Furthermore, a merchant also need to document what those components do and why. As stated in the standard: “without an inventory, some system components could be forgotten, and be inadvertently excluded from the organization’s configuration standards”. Of course, it definitely makes sense.
Another interesting addition within the 3.0 version concerns service providers. Requirement 8.5.1 mandates that service providers with remote access to CDEs “must use unique authentication credentials (such as a password/phrase) for each customer” that of course mitigates security risks in case of a data leak by the service provider.
Another related change (requirements 12.8.5 and 12.9) requires organizations to formally document which PCI DSS requirements are managed by each of their service providers and which are managed by the organization itself. Moreover, organizations must maintain a written agreement with their service providers verifying that their provider maintains all applicable PCI DSS requirements. The last requirement will eligible after July 1st, 2015.
Physical Access & PoS Devices
Surely, the changes should cover the physical access and point-of-sale (PoS) devices that capture payment card data directly from customer cards.
For the first part, the new 9.3 requirement mandates that merchants must control access to the CDE in accordance with an individual`s job function. What is important, it is also required to immediately revoke any such access for each dismissed employee. These restrictions will certainly contribute to reducing internal threats.
Now, some words about changes within the requirements for PoS devices. The 3.0 version requires several new controls to protect PoS devices from tampering and substitution which are described within requirement 9.9. To meet these new requirements, many organizations will need to develop and document policies and procedures, such as maintaining up-to-date inventories of PoS devices, performing periodic PoS inspections and providing employee training about PoS security. This requirement will be mandatory after July 1st, 2015.
Additional requirements were also added within the malware protection section.
Requirement 5.1.2 requires merchants to: “identify and evaluate evolving malware threats” for “systems considered to be not commonly affected by malicious software.” In simple words, it means if you use any “virus resistant” system (ex. Linux, UNIX servers), you will have to be aware about all new vulnerabilities and malwares for those platforms.
Another innovation (requirement 5.3) mandates specific authorization from management to disable or alter the operation of antivirus mechanisms, and that the disabling should be “on a case-by-case basis for a limited time period”.
As you can see, the newest version of the standard has significant changes which need to be taken into account. PCI SSC did tremendous job of collecting and compiling feedback. Also the industry is not standing still but moving forward. Thus, the third version is but the logical evolution of the standard which will be considered current for the following three years.
Of the disadvantages, it should be noted that the version 3.0 doesn`t contain any clarification for mobile payment processing or mobile device security, leaving merchants who use or support mobile payment technology virtually on their own to determine how to maintain PCI compliance.
In closing, I would like to wish good luck to all of us who will have to be compliant with the PCI DSS version 3.0 in the coming year.