PCI DSS v3.0 – What does it mean for me? Anne Wood | PCI QSA Senior Consultant, Sysnet Global Solutions

Extract This document describes some of the main changes proposed in the recent PCI DSS v3.0 draft and how you can ensure your business is able to meet the new standard.

Introduction The PCI SSC operates to a three year development lifecycle for its Payment Card Security Standards. New versions of the PCI DSS and PA-DSS are to be published in November 2013, and will become active from January 2014. From January 2015, organizations will no longer be able to report using PCI DSS v2.0 and will be required to attest compliance with PCI DSS v3.0. In its Version 3.0 Changes Highlights1 document, the PCI SSC stated that their key themes driving the changes to the PCI DSS are based upon education and awareness, increased flexibility, and security as a shared responsibility. These themes aim to address common challenge areas faced by the community and which present the greatest risks to an organization’s security: ■ ■ ■ ■

Lack of education and awareness Weak passwords and authentication practices Third party risks Limited capability to detect breaches and/or malware

In addition, the PCI SSC aims to provide further clarity around testing procedures to address the challenge of inconsistencies in assessments in this draft. So, what’s changed and how will it affect you?

Documenting your environment One of the major changes proposed in PCI DSS v3.0 is the increased requirement for documenting your network, card data flows and device inventories. PCI DSS v2.0 included requirements for a current network diagram2, an inventory log of all stored media, lists of

1 2

https://www.pcisecuritystandards.org/documents/DSS_and_PA-DSS_Change_Highlights.pdf For guidance on developing a network diagram, see Sysnet Factsheet What is a Network Diagram?

issued devices and a list of company approved products, and a list of service providers. The PCI DSS v3.0 draft also includes requirements for: ■ ■ ■ ■

A current card data flow diagram3 An inventory of in scope system components An up-to-date list of POS devices and terminals An inventory of authorised wireless access points

These additional inventory requirements aim to ensure that organizations have a full understanding of their cardholder data environment (CDE). You should work to develop a card data flow diagram, and to document your device inventories. There is no specific guidance as to how device inventories are to be reported; this could be anything from an Excel spreadsheet or Access database, to an Enterprise Asset Management tool. Organizations are required to scope their CDE prior to assessment. A PCI Qualified Security Assessor (QSA) has to validate the scope for assessment but they should not be required to identify the scope on behalf of the assessing organization. These additional inventory requirements will go some way to assisting the QSA in validating your scope and will enable a smoother and more effective assessment process.

Protecting stored data The PCI DSS v3.0 draft explicitly states that Sensitive Authentication Data (SAD) must not be stored after authorization, even when there is no PAN in the environment. This is a clarification to the same requirement in PCI DSS v2.0 and will impact any organization storing SAD whether or not they also store associated PAN data. If you have any stored SAD data, you need to ensure that it is securely destroyed such that it cannot be recovered, and modify systems and/or processes to ensure that this data is no longer stored post authorization. PAN can be stored post-authorization, providing it is stored in a secure manner. Guidance for securing PAN advises the use of a salt value4 when hashing PANs for electronic storage. This is a recommendation and not a requirement, however if you store hashed PANs, you may wish to review your systems and introduce the use of salted values as a best practice. For organizations that store encrypted PAN data and have responsibility for the associated key management there are additional controls that define key storage requirements for private keys. The requirement for key encrypting keys and data encrypting keys to be stored separately remains and is enhanced with additional requirements that keys are to be stored within a secure cryptographic module, or as two full length key components or key shares in accordance with industry-accepted methods. If you store encrypted PAN, you may need to review your key management processes to ensure that they meet these 3

For guidance on how to develop a card data flow diagram, see Sysnet Factsheet What is a Card Data Flow Diagram? A ‘Salt’ is an additional random input of digits added to a value prior to hashing to reduce the possibility that an attacker could compare the data against tables of pre-computed hash values, and thereby derive the original value. 4

new obligations, particularly that manual key management operations follow the updated definitions of split knowledge and dual control. It is common that there is at least some shared knowledge for access to key portions and organizations need to protect against this in order to satisfy the updated PCI DSS requirements.

Securing systems and devices A number of changes have been introduced to enhance the security of systems, including additional physical security and anti-malware controls, and enhanced software development and system testing requirements. A new requirement has been introduced for the physical security of POS terminals and will have a significant impact on retail merchants. To protect their POS devices, organizations are required to: ■ ■ ■

Maintain an up to date list of POS devices (as above) Periodically inspect devices to detect tampering Provide training to personnel enabling them to identify tampering or device substitution

You will need to introduce procedures and appropriate training programs to ensure your personnel are able to perform inspections and understand what they are looking for. System security obligations have also been reviewed as part of the updated standard. PCI DSS v2.0 required anti-malware solutions to be deployed on ‘systems commonly affected by malware’. In the PCI DSS v3.0 draft, systems that are considered to be ‘not commonly affected by malware’ should be evaluated against evolving malware threats to identify whether anti-malware solutions should be applied to them. Organizations need to be aware that the malware threat is not limited to Windows as it had been considered in the past. Malware threats are constantly evolving and iOS, and other operating systems, as well as mainframe and other computing systems are not immune to malware and organizations must have a process in place to identify when new malware poses a significant threat to their infrastructure. Penetration testing requirements in PCI DSS v2.0 resulted in a number of queries from organizations working towards compliance. The PCI DSS v3.0 draft aims to clarify penetration testing obligations and provides a more detailed methodology for conducting penetration tests. Penetration tests are now specifically required to follow industryaccepted approaches, and must cover at least the perimeter of the CDE and critical systems within it. Furthermore, penetration testing is also required to validate any segmentation implemented by a transition to reduce their compliance scope. Evidence that segmentation is effective and complete will be required by the QSA to validate the scope of assessment. You may need to enhance current penetration testing procedures to ensure that they satisfy these new testing criteria.

Managing and educating users The PCI DSS v3.0 draft provides a comprehensive policy framework that can be used by organizations to develop policies and operating procedures. The need for a documented policy and associated operational procedures is now included for each PCI DSS requirement. Organizations can choose how they design security policies and procedures for their business—they do not have to be in twelve separate policies—but PCI DSS v3.0 offers a structure that may assist businesses developing policies for the first time. In addition, there is an important clarification in the new standard that business functions or individuals responsible for monitoring or auditing security controls should not be responsible for administering the same controls. While PCI DSS v2.0 required systems access to be managed on an ‘as-needed’ basis, the v3.0 draft takes this one step further and requires that organizations document defined accesses per job role. You should review your access control processes and identify standard access profiles for each job role. Any exceptions to these profiles will need to be documented and justified as part of the access request process. In addition, password controls have been revised to include specific training provision to users in the creation of strong passwords and secure password management techniques. This is an additional training requirement, over and above the security awareness training required by PCI DSS v2.0. A new requirement to lock system consoles when they are not in use is also included to prevent unauthorized use of consoles and workstations.

Service providers The PCI SSC has revised a number of controls clarifying the relationship between organizations and their service providers, and how responsibility for PCI DSS compliance must be documented between entities. Responsibility for compliance applies to all entities that store, process or transmit cardholder data. For those entities who chose to outsource their payment operations or management of their cardholder data environment, responsibility for ensuring that PCI DSS compliance requirements are met for those outsourced services will remain with them. Responsibility for compliance cannot be outsourced. To support this position, the PCI DSS v3.0 draft requires organizations to maintain control responsibility documentation for each service provider relationship defining which party is responsible for each control. The written agreements between organizations and their service providers should also be enhanced to include an agreement that service providers will maintain all applicable PCI DSS requirements as defined by the responsibilities document. Further, service providers are required to provide an acknowledgement in writing to their customers that they will maintain all applicable requirements. You should review your service provider relationships and work, in association with your providers, to define a controls responsibility matrix for each. Compliance with some controls may be a

shared responsibility, with each party responsible for defined elements of a control. For example, an outsourced hosting provider may be responsible for applying OS patches or updates to hosted servers, and the merchant may be responsible for patch management of applications running on those same servers. These scenarios should be documented to ensure that lines of accountability are clearly defined.

Assessment and maintaining compliance The PCI DSS v3.0 draft introduces a significant number of additional testing procedures that must be validated in an assessment. For organizations required to undergo a formal QSA assessment, this may result in slightly extended assessment timescales. Organizations wishing to minimize this should work with their QSA Company to define a plan for their assessment, understand the Report on Compliance (ROC) evidence requirements and collate that evidence, where possible, in advance of the assessment. Organizations are provided guidance within the PCI DSS v3.0 draft to integrate PCI DSS activities into Business-As-Usual (BAU). Organizations that successfully integrate compliance activities into BAU operations will find that the maintenance overhead of compliance becomes more manageable and cost effective. This should directly contribute to an efficient assessment since preparation for assessment will also be integrated into standard processes.

What do I do now? The PCI DSS v3.0 draft offers far greater guidance and clarification of requirements than in previous PCI DSS versions. For organizations that are compliant with PCI DSS v2.0, some controls will need to be updated to meet the new testing procedures. However, a majority of organizations that are compliant with PCI DSS v2.0 should be able to achieve compliance with PCI DSS v3.0 without incurring significant costs. The changes between v2.0 and v3.0 are evolutionary, not revolutionary; there is a refinement of controls and you should not feel over-faced by the new standard. To ease the transition from PCI DSS v2.0 to PCI DSS v3.0, you can begin to develop the additional inventory material and review existing process as described in this paper as you continue to work towards compliance, even if you are preparing for an assessment. Organizations that have not been assessed against PCI DSS v2.0 and are working towards compliance should consult their QSA to determine whether it is appropriate to migrate to PCI DSS v3.0 prior to an initial assessment.

About Sysnet Global Solutions Established in 1989, Sysnet Global Solutions provides payment card industry compliance services, specialising in PCI DSS compliance validation and merchant intelligence solutions Sysnet offers a range of services, including its proprietary web based compliance management and merchant intelligence solution sysnet.air™, to a wide variety of businesses including acquirers, ISOs, international banks, payment service providers and merchants. Sysnet has more than 20 years’ experience in multiple IT environments and its expert engineering and consulting teams are certified to the highest standards. Headquartered in Dublin, Ireland, Sysnet has clients in over 35 countries worldwide.