The current version of The Payment Card Industries Data Security Standard (PCI DSS) is version 1.1 and was published in October of 2006. PCI DSS was established by Visa, MasterCard and others to protect cardholder payment data. Any business that accepts or processes payment cards must comply with the PCI DSS. Depending on the number and type of transactions conducted by an organization either a self-assessment[1] or a yearly audit is necessary to show compliance to PCI DSS. Additionally, security scans that have to be conducted regularly complement the audit process.

As the establishing, maintenance and improvement of an ISMS is a continuous process, the same can be said about achieving PCI compliance where the PCI council defines the three-step process of Assess-Remediate-Report as shown in Figure 1.

In the assess step IT assets and business processes for payment card processing are inventoried and analyzed for vulnerabilities that could expose cardholder data. During the remediate step the vulnerabilities found in the first step are fixed. The report step entails the compilation of records required by PCI DSS. The three processes are carried out repeatedly for continuous compliance to PCI DSS and are easily integrated into a PDCA cycle as used for an ISMS. 

Figure 1: The processes defined for PCI DSS.

MasterCard has incorporated PCI DSS into its Site Data Protection (SDP) program and defines the following two levels:

Level 1, which includes all Third Party Providers (TTP) and all Data Storage Entities (DSE) that store, transmit or process greater than 1 million total combined MasterCard and Maestro transactions annually. Level 1 service providers need to conduct a yearly audit and quarterly security scans.

Level 2, which includes all DSE’s that store, transmit, or process less than 1 million total combined MasterCard and Maestro transactions annually. Level 2 service providers need to annually fill out a Self-Assessment Questionnaire (SAQ) and conduct quarterly security scans.

VISA has incorporated PCI DSS into its Cardholder Information Security Program (CISP). It defines 3 levels for service providers with Level 2 and Level 3 service providers comparable to Level 1 and Level 2 service providers in the MasterCard SDP. Additionally Level 1 service providers – which have the same validation requirements as Level 2 service providers – include all VisaNet processors and all payment gateways.

Additionally, SDP and CISP define 4 levels with different validation needs for merchants that process transactions[2].

Interestingly, although PCI DSS is a joint effort, there is no requirement for a service provider that is SDP, Level 2 and CISP, Level 3, with a combined amount of more than 1 million transactions to conduct a yearly audit[3].

The main reasons for setting up PCI DSS were multiple, recurring cases of data compromise that covered all types of organizations, from very small to very large merchants and service providers. Security breaches involving compromise of payment data may have far-reaching consequences for affected organizations, including:

Regulatory notification requirements,

• Loss of reputation,
• Loss of customers,
• Potential financial liabilities (e.g. regulatory and other fees and fines) and,
• Litigation.

Investigations of security breaches often show(ed) common PCI DSS violations, including:

• Storage of magnetic stripe data.
• Inadequate access control.
• Default system settings and passwords.
• Unnecessary and vulnerable services not removed or fixed.
• Poorly coded web applications resulting in SQL injection and other vulnerabilities.
• Missing and outdated security patches.
• Lack of logging.
• Lack of monitoring.
• Lack of segmentation in a network.

PCI DSS covers the data shown in Table 1 that has to be secured and sets out the security requirements that have to be followed to achieve the security goals. Entries in Table 1 that are marked with an asterisk only have to be secured if they are stored together with the PAN.

The requirements of PCI DSS apply to all “system components” which includes any IT component, i.e. network components, servers or applications that are included in or connected to the cardholder data environment. The cardholder data environment is the part of the network that processes cardholder data or sensitive authentication data. The definition of system components encourages the isolation of systems that work with sensitive data to limit the scope of the cardholder data environment.

Table 1: Security relevant data and information covered by PCI DSS.

PCI DSS is a security best-practices approach that covers six major security goals (called control objectives) through 12 requirements that define the necessary security sub-requirements that have to be set up by an organization that wants to comply with the standard. Most PCI DSS (sub-) requirements can be substituted by compensating controls if the underlying risk that should be mitigated by the defined control can also be sufficiently mitigated by the compensating control.

The definition of control objectives, requirements and sub-requirements is similar to the control objectives, categories and controls in ISO 27001 with requirements being roughly equivalent to controls and sub-requirements being much finer-grained. Table 2 gives an overview of the contents and Table 3 contains a detailed break up of control objectives, requirements and sub-requirements[4]. 

Table 2: Overview of control objectives, requirements and controls in PCI DSS.

Table 3: Detailed break-up of control objectives requirements and controls in PCI DSS.

Contrary to ISO 27001, the goals and requirements are very specific and tailored to the storage, processing and transmission of PAN data. Due to the narrow scope of PCI DSS as opposed to ISO 27001 the PCI DSS council gives detailed information about the audit process which is described in the PCI DSS Security Assessment Procedures.

To guarantee the quality of onsite audits and of the quarterly security scans the PCI DSS council provides mandatory validation requirements for Qualified Security Assessors (QSAs) and for Approved Scanning Vendors (ASV). Reports of a QSA or an ASV are distributed to and accepted by the relevant scheme operator (e.g. MasterCard for service providers who are obligated to conform to SDP). While the scheme operator accepts such reports it always reserves the rights to check up on any report and may investigate any report results in question, which might be of importance for the implementation of controls that rely on the interpretation of the assessor, e.g. compensating controls.

Accompanying PCI DSS are two additional standards to assess the security of payment applications and of pin entry devices (PED), namely the:

• Payment Application Data Security Standard (PA-DSS), that covers compliance to PCI DSS of payment applications that are sold, distributed or licensed to third parties. This standard does not effect in-house payment applications that are subject to PCI DSS requirements. The PA-DSS is the offspring of the Payment Application Best Practices Program (PABP) that was overseen by VISA.
• PIN Entry Devices, which assesses the compliance of PEDs to security requirements.

PCI DSS is regularly maintained and updated.  The new version 1.2 will replace the current version 1.1 on October 1, 2008. The new version will be available for Participating Organizations by the first week of September. The new version will not introduce any major new requirements but was designed to fulfil the following goals:

• Provide greater clarity on PCI DSS requirements.
• Offer improved flexibility.
• Manage any evolving risks and threats.
• Incorporate best practices.
• Clarify scoping and reporting.
• Eliminate redundant sub-requirements.
• Consolidate documentation.

Participation in the PCI Security Standards Council, LLC is open to all entities that participate in the payment processing system. Participation costs USD $2000,- per year. Accepted organizations have the opportunity to:

• Vote for Participating Organization representatives on the PCI Security Standards Council Board of Advisors.
• Nominate a representative to stand for election to the PCI Security Standards Council Board of Advisors.
• Comment on drafts of all revisions to the DSS specification, and on any new specifications, prior to public release.
• Attend Community Meetings hosted by the PCI Security Standards Council.
• Recommend new initiatives for consideration to the PCI Security Standards Council.