Payment Card Industry Data Security Standard in the Real World 

 
Download Article

In response to growing concern about the misuse of stored information about credit and debit cards, the four major card-issuing bodies took steps to regulate the payment card-industry through the introduction of strict security procedures that govern how cardholder data are stored, processed and transmitted. Now collectively referred to as the Payment Card Industry (PCI) Data Security Standard (DSS), all member organizations that issue or acquire information from cards labeled with the Visa, MasterCard, American Express and Discover logos are required to comply with the requirements for auditing, scanning and assessment outlined in PCI DSS. While the common standard simplified the process that card issuers and acquirers were subjected to originally—no longer were they required to follow up to four separate programs applied differently in each region or country of operation—the new PCI DSS has introduced its own set of complexities.

How PCI DSS Works

PCI DSS originally began as four different programs: Visa’s Card Information Security Program, MasterCard’s Site Data Protection, American Express’s Data Security Operating Policy, and Discover’s Information and Compliance. Each company’s intention was roughly similar: to create an additional level of protection for customers by ensuring that merchants meet minimum levels of security when they store, process and transmit cardholder data.

In December 2007, the four card issuers aligned their individual policies to create one overarching standard: PCI DSS. The standard sets forth common requirements for auditing, scanning and assessment, which ensure that vendors do not have to go through multiple programs to make certain that their environments comply with each individual card company’s standards. The standard also provides a common implementation schedule, levels and participation criteria for merchants and service providers, as well as cross-recognition of qualified onsite assessors and compliant scanning vendors in Canada, Europe and the US.

PCI is made up of member organizations, which are classified as acquirers and issuers, and a few select players who perform both functions. While the terminology is somewhat arcane, the basic distinction is that acquirers handle the merchants that conduct transactions, while issuers are responsible for the issuing of cards to cardholders. A final group—service providers—are the entities that provide any service requiring the processing, storing or transportation of card information at the request of either acquirers or issuers.

The PCI Security Standards Council (PCICo) sets the highlevel requirements, but each card association implements and enforces the standard, fines/fees, and compliance levels and deadlines. Despite being a global standard, PCI DSS is subject to minor variations based on both the card association and, in the case of Visa, physical location. The most notable difference is that MasterCard implements its programs globally, but Visa implements PCI DSS on a regional level, in keeping with its overall business, and this results in small variations. For example, level 1 merchants in the US can perform their onsite audit with the use of internal audit staff instead of using a Qualified Security Assessor (QSA), as long as they have the report on compliance (RoC) authorized by an officer of the corporation. This is not an option in Asia-Pacific because of different corporate governance issues there.

PCI DSS uses levels to determine compliance validation requirements. For merchants (figure 1), their level is determined primarily by the volume of credit card transactions performed, but a history of data breaches can force smaller merchants into the top tier. All service providers that are credit card processors or payment gateways are level 1; level 2 and level 3 are service providers that do not fall into this category, determined by the volume of cards processed as displayed in figure 2. The levels are card-specific and differ for each card company. In the case of Visa, which operates regionally, there are differences in the levels according to geographic region. Merchants should always contact their acquirer to determine their level.

figure 1
figure 2

Regardless of the level in which a service provider or merchant falls, it does not impact the requirements—they are the same across all levels. The level impacts only the validation requirements.

The most stringent validation requirements are reserved for level 1 and 2 service providers and for level 1 merchants .Providers and merchants in these levels must meet the DSS, conduct and pass an annual penetration test, conduct quarterly scans, and complete and pass an annual audit using external auditors. For level 2 and 3 merchants, the formal external audit requirement is replaced with an annual self-assessment, which must be approved by a qualified QSA. For level 4 merchants, all requirements, except meeting the DSS, are listed as optional. However, even at this level, failure to protect data adequately, as demonstrated by breaches or other data compromises, will result in the merchant’s immediate “elevation” to level 1 status.

The PCICo manages the DSS, but it does not specify what the result of a failure to comply will involve. The individual card companies are responsible for setting those rules, and penalties can range from fines to suspension of the ability to accept credit cards. In the case of the card company having agreements with the acquirer rather than the merchant, the acquirer will be held responsible for a security breach within its merchant community. Acquirers are able to pass on these penalties to the offending merchant or service provider through their contractual relationships.

The requirements for each level are shown in figure 3. The asterisk denotes that this requirement is at the acquirer’s discretion.

figure 3

The requirements for PCI DSS are based on security breach analysis done by the card companies. The requirements, therefore, are based on real-world security analysis and, when implemented properly, should ensure that a company is secured against the most common types of attacks. Figure 4 describes the top five reasons for account data compromise, according to MasterCard forensics analysis post-incident.

figure 4

PCI DSS Requirements

To be compliant with PCI DSS, all enterprises must meet 12 requirements. While these requirements appear to be straightforward on the surface, they map to in excess of 200 subrequirements as outlined in the PCI Security Audit Procedures.1 The 12 basic requirements are as follows:

  1. Install and maintain a firewall configuration to protect cardholder data.
  2. Do not use vendor-supplied defaults for system passwords and other security parameters.
  3. Protect stored cardholder data.
  4. Encrypt transmission of cardholder data across open, public networks.
  5. Use and regularly update antivirus software.
  6. Develop and maintain secure systems and applications.
  7. Restrict access to cardholder data by business on a need-to-know basis.
  8. Assign a unique ID to each person with computer access.
  9. Restrict physical access to cardholder data.
  10. Track and monitor all access to network resources and cardholder data.
  11. Regularly test security systems and processes.
  12. Maintain a policy that addresses information security.

The PCI DSS security requirements apply to all system components. A system component is defined as any network component, server or application that is included in, or connected to, the cardholder data environment. The cardholder data environment is that part of the network that possesses cardholder data or sensitive authentication data. Network components include, but are not limited to, firewalls, switches, routers, wireless access points, network appliances and other security appliances. Server types include, but are not limited to, web, database, authentication, mail, proxy, Network Time Protocol (NTP) and Domain Name Server (DNS). Applications include all purchased and custom applications, including internal and external (Internet) applications. The scope of PCI DSS encompasses all systems that process, store or transmit cardholder information, as well as other systems that are in the same network zone. PCI DSS defines network zones as all systems that share a common boundary. Network zones are separated by stateful packet inspection.

If there is no external access to the merchant location by Internet, wireless, virtual private network (VPN), dial-in, broadband or publicly accessible machines (such as kiosks), the point-of-sale (POS) environment may be excluded. However, in reality, most POS systems have some form of remote access either from the corporation (frame-relay or VPN), or are managed remotely and are, therefore, within the scope of PCI DSS requirements.

A Typical PCI Engagement

On average, PCI projects last between 12 and 18 months. They begin with the creation of a data flow diagram to determine which systems contain sensitive PCI data. The second part of the engagement requires a risk and vulnerability assessment to be performed on all system components in the cardholder data environment to determine where vulnerabilities need to be addressed. The initial gap analysis and remediation is the biggest hurdle for companies to overcome.

Scanning is the third key component of the engagement and identifies those systems that are not patched, those that contain known vulnerabilities, and weaknesses resulting from default accounts and blank passwords. While internal and external scans need to be completed on a quarterly basis, only the results from the external scans need to be submitted to PCICo. Merchants and service providers need to be mindful of the fact that a scan is considered valid only if it is conducted by an authorized scanning vendor (ASV).2

Likewise, merchants and service providers that require an audit must have the work performed by a QSA,3 who then creates an RoC to be submitted to the acquiring bank.

If an enterprise is not compliant, it must submit a clear plan detailing how compliance will be achieved. This plan is monitored by the company’s QSA and acquirer. It may be possible to use compensating controls4 to meet a requirement, but the compensating control must be over and above what is already specified and must meet the intent of the DSS requirement. Any compensating control is at the discretion of the QSA and must be agreed to by the acquirer.

A very small percentage of customers is compliant to PCI DSS without any form of remediation. Drawing on the experience of the PCI audit team, most enterprises store credit card data in multiple locations and the information is rarely encrypted. Additionally, information that is now prohibited from being stored, such as Card Verification Value 2 (CVV2) or personal identification numbers (PINs), is often found stored in multiple locations. Investigating all the potential places, such as log files, where this information might be stored, is not easy and is made more difficult by the complex nature of the environment. As a result, enterprises often need to review their data retention policies and re-create backup tapes with the information appropriately secured.

In a large complex network, remediating against default accounts and passwords can cause a huge problem. Creating a compensating control, while appropriately built standards are created and the problem remediated, can put immediate controls in place to reduce risk, while a more secure permanent solution is deployed. An example of this would be enabling Secure Shell (SSH) for remote administration and allowing only the remote administration to occur from a secured terminal.

Application vulnerabilities are one of the top security problems. For example, in one case, an enterprise believed because a password was stored within an executable program that the application was secured. The QSA simply used a UNIX utility called “Strings” to examine the binary code of the program and easily revealed the password.

Developers build applications for functionality and frequently do not build security into the requirements. Security becomes an afterthought. Penetration testing at the application level is crucial to understand what vulnerabilities exist. Careless coding is something that can be reduced through good development practices, but to err is human and, therefore, coding errors will never disappear.

A plethora of database intruder-prevention-style appliances is gaining popularity in the marketplace. These appliances will monitor each transaction, looking for activity that corresponds to an attack, such as SQL injection, and raise alerts. Security policies such as the maximum number of credit cards that should be accessed within a day can be configured on these devices, so that they can alert upon policy violations.

The most common egregious PCI DSS audit failures are:
  1. Requirement 3: Protect stored data.
  2. Requirement 11: Regularly test security systems and processes.
  3. Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
  4. Requirement 10: Track and monitor all access to network resources and cardholder data.
  5. Requirement 8: Assign a unique ID to each person with computer access.
  6. Requirement 6: Develop and maintain secure systems and applications.
  7. Requirement 12: Maintain a policy that addresses information security.
  8. Requirement 9: Restrict physical access to cardholder data.
  9. Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks.
  10. Requirement 1: Install and maintain a firewall configuration to protect data.

Ongoing Assessment

PCI requires sustained compliance as verified by each level’s validation requirements. It is expected that the standard will change to address emerging threats. Companies will have to adjust to meet these new requirements to remain compliant. By raising the enterprise’s information security maturity level, it is possible to reduce the cost of the ongoing annual audits. With the right choice of tools, enterprises can defensibly demonstrate their adherence to a broad spectrum of corporate standards and regulations, including PCI compliance, the US Sarbanes-Oxley Act and Health Insurance Portability and Accountability Act, while increasing overall security, achieving continuous compliance, and lowering the cost and complexity of their IT infrastructure.

An example of using tools to simplify the audit process is using a configuration management tool that provides ready-to deploy support, such as the Center for Internet Security (CIS)’s configuration templates, which are specifically mentioned within the PCI DSS standard. The auditor can look within the management tool’s console to ensure that the machines are compliant with a recognized best practice without using sampling techniques. For a large enterprise, this can represent a considerable savings, where the alternative is a manual sampling of 10-15 percent of the machines and the cost of an audit is US $100-$200 per hour.

Another example of tools simplifying the audit process is using a policy management tool. Requirement 12 of PCI DSS specifies that the enterprise has a policy in place that meets all the security requirements outlined within the DSS. The key is that the policy must meet the requirements, and subrequirements are outlined within the standard. Policy management tools map existing policy back to the PCI DSS requirements, allowing an auditor to see at a glance that the existing enterprise’s security policy meets the requirements outlined within the DSS.

Conclusion: The Future of PCI DSS

PCI DSS is by no means perfect, but it does provide useful guidance as to the controls that should be used to protect sensitive data. The standard can be used not only to protect credit card data but all personally identifiable information. In 2008, with the advent of Single Euro Payments Area (SEPA), European countries will start cobranding their bank cards with one or more of the card association logos. This will result in a significantly larger number of merchants and service providers in Europe being classified by PCI DSS as level 1 or 2. There have been corresponding noises about introducing consumer data breach notification laws in the European Union (EU) parliament. On 11 May 2007, the Texas (USA) House of Representatives unanimously passed HB 3222, which mandates that businesses that accept payment cards comply with all PCI DSS requirements, effective 1 January 2009. Other states in the US are introducing bills that cover some of the PCI DSS requirements.

The number of security breaches will no doubt continue to increase, and there will be a corresponding increase in legislation globally to force enterprises to put in security measures to protect personal information. The ability to store information about an individual should be seen as a privilege and not a right. Enterprises that do not protect the information should and will have that privilege removed.

Endnotes

1Details of the 200 subrequirements are outlined in the security audit procedures at https://www.pcisecuritystandards.org/security_standards/supporting_documents.shtml.
2A list of authorized vendors can be found at https://www.pcisecuritystandards.org/pdfs/asv_report.html.
3A list of qualified assessors can be found at https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf.
4For a definition of PCI compensating controls, please see https://www.pcisecuritystandards.org/security_standards/glossary.shtml

Author’s Note

The authors would like to thank Jenna Sindle for her editorial assistance.

Doug Drew, CISSP, PCI QSA
is a senior security consultant at BT INS. Drew has more than 10 years of experience in information security and has taught incident response and forensics at the collegiate level. He has been working with the PCI standard since 2006 and has conducted numerous PCI engagements for BT INS, covering a diverse range of industries. Drew specializes in risk management, regulatory compliance and security program development, serving as a trusted advisor to Fortune 500 companies.

Sushila Nair, CISA, CISSP, BS 7799 LA, PCI QSA
is a product manager at BT Counterpane and responsible for compliance products. Nair brings 20 years of experience in computing infrastructure and business security as well as a diverse background, including work in the telecommunications sector, risk analysis, credit card fraud and experience as an expert legal witness. She has worked with the insurance industry in Europe and the US on methods of quantifying risk for e-insurance based on ISO 27001. She was instrumental in creating the first banking group in Malaysia focused on using secondary authentication devices for banking transactions. Nair has worked extensively with customers of BT to develop monitoring solutions that meet the needs of regulatory compliance, including that of PCI DSS.


Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the ISACA. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.