1

Payment Card Industry Data Security Standard - PCI DSS Executive Summary

PCI Compliance: Business Owners / IT Managers Guide

PCI Standards must be met by all businesses that take credit/debit or pay cards from the top four major card industry providers: American Express, Discover, MasterCard and Visa. PCI Compliance Standards are not laws – they are contractual obligations with the credit card companies. Credit card companies may enforce the terms of their contracts by imposing fines and/or sanctions against companies who do no comply with the standards for each credit card company.

What is Payment Card Industry (PCI) Compliance?

Payment Card Industry (PCI) Compliance is a set of security standards that were created by the major credit card companies (American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International) to protect their customers from increasing identity theft and security breaches. Under the PCI DSS, a business or organization should be able to assure their customers that its credit card data/account information and transaction information is safe from hackers or any malicious system intrusion

Do I need to become compliant?

Any company that accepts, processes, or stores credit card information needs to comply with the standards set by the Payment Card Industry. This includes POS software vendors, 3rd party service providers, merchants of all types, and any other entity who is part of the payment transaction process.

What are my requirements for PCI Compliance?

The requirements for becoming Payment Card Industry (PCI) Compliant are dependent upon the merchant level that a company falls under. Merchants are divided into four different levels based on the number of transactions they process throughout a year. Level 1 Criteria Merchants with over 6 million transactions a year Merchants whose data has been compromised Level 1 Requirements Annual Onsite Security Audit and quarterly network security scan Level 2 Criteria Merchants with 150,000 to 6 million transactions a year Level 2 Requirements Annual Self Assessment Questionnaire

2

Quarterly Scan by an Approved PCI Scanning Vendor Level 3 Criteria Merchants with 20,000 to 150,000 transactions a year Level 3 Requirements Quarterly Scan by an Approved PCI Scanning Vendor Annual Self Assessment Questionnaire Level 4 Criteria Merchants with less than 20,000 transactions Level 4 Requirements No need to report compliance but must maintain compliance.

What kind of a scan needs to be performed?

Vulnerability Assessment Scans must be performed by Payment Card Industry Approved Scanning Vendors (ASV). The scan will be performed over all externally facing IP addresses that touch the credit card acceptance, transmission and storage process. Scans must be turned into the merchant bank on a quarterly basis.

How do I report compliance?

Both the passing PCI Scan and Annual Self Assessment Questionnaire should be turned into your merchant bank. Your merchant bank will then report back to the Payment Card Industry that your company is PCI Compliant.

What happens if I am not compliant?

Failure to comply with the Payment Card Industry security standards may result in heavy fines, restrictions, or permanent expulsion from card acceptance programs.

Card companies may impose fines on their member banking institutions when merchants are found to be non-compliant with PCI DSS. Acquiring banks may in turn contractually oblige merchants to indemnify and reimburse them for such fines. Fines could go up to $500,000 per incident if data is compromised and merchants are found to be non-compliant. In the worst case scenario, merchants could also risk losing the ability to process customers' credit card transactions. Source: www.pcicomplianceguide.org

3

TABLE OF CONTENTS Executive Summary 1

Introduction to PCI DSS 4

Finding PCI DSS Compliance Level 6

Visa CISP Program 8

MasterCard SDA Program 8

Defining Merchant Levels 9

Defining Service Provider Levels 13

Acquirer PCI Responsibility 14

Enforcement Dates 15

Visa & MasterCard Quick Reference Guides 16

Attaining PCI Compliance- Merchants 18

PCI DSS 12 Requirements 19

Finding PCI Approved Scanning Vendors 25

Compliance Reporting 29

PCI DSS Self Questionnaire 31

Cardholder Data Theft- Real Cases 33

4

PCI DSS: A Five Step Guide to PCI Compliance

Step 1: An Introduction to PCI Compliance

Payment Card Industry (PCI) Compliance is a set of security standards that were created by the major credit card companies (American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International) to protect their customers from increasing identity theft and security breaches.

The PCI Data Security Standard (PCI DSS) really began with each credit card issuer establishing their own proprietary programs to store and secure credit card data. Merchant concerns and confusion concerning rival and intersecting card brand-specific requirements, along with the continuation of massive credit card data breaches at many high profile organizations, prompted the card issuers to come together to create a single standard for protecting credit card data. In June 2005, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International founded the PCI Security Council. These requirements are based on ISO 17799-the internationally recognized standard for information security practices. The main tasks of the council are:

• Creating, owning and managing PCI DSS for credit card data • Classifying a common audit requirement to certify compliance • Overseeing a certification process for security assessors and network scanning

vendors • Instituting minimum qualification requirements • Retaining and publishing a list of certified assessors and vendors

Question: What can happen to you and/or your organization, if you fail to implement or adhere to, the Payment Card Industry Data Security (PCI DSS) compliance rules? Answer: Ask TJX Companies Inc. (TJX). Currently, the company-owner of T.J. Maxx and Marshall's department stores and other stores in North America and the United Kingdom-faces more than a dozen class action lawsuits in Alabama, California, Massachusetts, Puerto Rico and six Canadian provinces, for what has been hailed as the single largest data breach in United States history. TJX revealed in March 2007 that hackers compromised at least 45.7 million credit and debit cards. From July 2005 until the discovery in December 2006, the bandits penetrated a supposedly secure network environment.

5

In a regulatory filing made with the Securities and Exchange Commission (SEC) after the violation, TJX stated that its computer systems were first hacked in July 2005 by one or more intruders who accessed information from customer transactions dating back to January 2003. TJX officials said that they didn't find out about the breach until about three months ago. More troubling, however, is the fact that TJX believes that the hackers had access to the decryption tool for their encryption software, making PIN numbers, credit card numbers, and any other unique identifiers easy to see. The SEC filing also said another 455,000 customers who returned merchandise without receipts had their driver's license numbers stolen. At this time, TJX is not sure whether it was a single breach, or multiple intrusions. The ripples of this breach are far reaching, including the addition of TJX's acquirer-Cincinnati-based Fifth Third Bancorp-as a defendant in some of the lawsuits. The bank processed some payment card transactions for TJX. TJX and its acquirer are not alone in not being cognizant of potential holes in their security systems, as there have been many examples of breaches that have compromised confidential information across several business sectors in the last decade alone. "Companies like LexisNexis, Citibank, and ChoicePoint have all had breaches," says Khalid Kark, senior security analyst with Forrester Research. Kark is a leading expert in Security and Risk Management, compliance, best practices, and services. "The issue is that it's not that the company doesn't have good security, it's just that they haven't really put in all of the effort and the time to understand all of the areas of threat and try to protect against those." Even with the guidelines, many organizations have not opted to pursue PCI Compliance, even when they may know that they need to be. At the same time Visa U.S.A projects that 65 percent of all merchants will be PCI compliant by the end of 2007, and stiff penalties that target acquirers is one tool that the PCI SSC. If an organization doesn't know that they need to be PCI compliant, or if an organization just doesn't want to be bothered by having to obtain PCI compliance, it soon will not matter. The goal is to have all merchants, regardless of their merchant level, compliant with PCI DSS. "Being PCI compliant is a smart business decision, as far as securing their [merchants] Web property and Intellectual property," said Aaron Biddar, president of ControlScan-a leading Internet security solutions company. "With data being stored virtually, in accessible areas, PCI standards are set up to help businesses with better practices," he continued. "These better practices can begin with 'hey, do you have a lock on your door?' to 'do you have scanning procedures in place?'…being PCI compliant, without being forced to do it, just makes good business sense, period." Who Put the DSS in PCI?

The Payment Card Industry (PCI) consists of the five major credit card brands:

6

• Visa • MasterCard • American Express • Discover Card • JCB International

The PCI Data Security Standard (PCI DSS) really began with each credit card issuer establishing their own proprietary programs to store and secure credit card data. Merchant concerns and confusion concerning rival and intersecting card brand-specific requirements, along with the continuation of massive credit card data breaches at many high profile organizations, prompted the card issuers to come together to create a single standard for protecting credit card data. In June 2005, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International founded the PCI Security Council. These requirements are based on ISO 17799-the internationally recognized standard for information security practices. The main tasks of the council are:

• Creating, owning and managing PCI DSS for credit card data • Classifying a common audit requirement to certify compliance • Overseeing a certification process for security assessors and network scanning

vendors • Instituting minimum qualification requirements • Retaining and publishing a list of certified assessors and vendors

Under the PCI DSS, a business or organization should be able to assure their customers that its credit card data/account information and transaction information is safe from hackers or any malicious system intrusion. The PCI Security Standards Council is not a policing organization. It neither enforces the PCI DSS, nor determines the appropriate remediation for violations of the PCI DSS. Enforcement is left the specific credit card companies and acquirers. PCI DSS does not replace the individual credit card company's compliance programs. Each credit card company separately determines who must be compliant, including any brand-specific enforcement programs.

Step 2: Finding the PCI DSS Merchant, Service, and Compliance Level

Should Your Organization be Concerned about PCI Compliance? The Payment Card Industry Data Security Standard (PCI DSS) applies to every organization that processes credit or debit card information, including merchants and third-party service providers that store, process or transmit credit card/debit card data.

7

If you are one of the above, PCI Compliance is not a request, or suggestion, it is now a requirement. However, according to the PCI DSS documentation, "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply." By the end of 2007, any organization that accepts payment card transactions must be in compliance with the standards. Credit card companies and acquirer banks can levy stiff fines and remove the merchant's ability to process credit card transactions until the merchant is PCI compliant. Basic rules on PCI DSS compliance:

• PCI DSS compliance includes merchants and service providers who accept, capture, store, transmit or process credit and debit card data.

• As of September 2006, PCI DSS 1.1 includes 12 major requirements. A single violation of any of the requirements can trigger an overall non-compliant status.

• Each non-compliant incident will result in steep fines, suspension and revocation of card processing privileges.

In a recent PCI Webinar hosted by Imprivata software and Forrester Research, Khalid Kark said that questions concerning how to determine whether a service provider needs to be PCI DSS compliant are very common. "I get these questions all of the time," he commented. "The rule of thumb is this: If you house credit card information, in whatever form, if you house the information in your server-the server that you own or you added-then you are basically responsible for complying with PCI DSS," Kark stated. Even with a uniform standard for compliance, since the PCI DSS Standards Council instituted the new security standards, evidence suggests that there has not been a huge rush to comply. Many organizations have started to comply or audit in certain areas, but overall numbers seesaw depending on the each merchant level. From data collected by Visa, in 2006 only 18 percent of Level 1 merchants-merchants with 6 million or more Visa transactions per year-were compliant with PCI DSS, as opposed to the 35 percent who are currently PCI compliant in 2007. Another 51 percent have completed a report concerning where they are in terms of compliance, and 93 percent of the responding merchants certified that they are not storing PIN numbers, card verification numbers and other stored credit card data. Only 26 percent of Level 2 merchants-merchants with 1 to 6 million Visa or MasterCard transactions per year-are PCI compliant at this time, but Level 3 merchants-merchants with Visa or MasterCard

8

transactions totaling 20,000 to 1 million-have a higher level of compliance at 51 percent. According to information gathered by Kark and Forrester Research, though organizations are spending a lot of money to become PCI compliant, it still is taking a long time for the organization to actually see the benefits of that compliance. "We've found that over years, typically there is one year there is a push to get spending, or to have spending in terms of a specific regulation," Kark explained. "In 2005, for government, it was VISMA [government compliance program] and there was a lot of spending in terms of getting the controls in place, getting the technology in place, and so on, and in 2006 we saw a similar trend in the retail industry where the retail industry spent a lot of money in terms of getting compliant with PCI." Continuing, Kark said that implementing a PCI DSS compliance program is still a lengthy process. "Once you start implementing technologies, once you start investing in security controls, then it takes a couple of years from implementation to realize the benefits of that spending," he said. "And to be able to get to the fact of 'well, yes we are compliant completely, and yes we spent the money a couple of years ahead of time, but then we needed to put in processes and other things that we're kind of realizing the benefits of that spending.'" From surveys conducted by Forrester Research, Kark believes that most companies will be compliant with PCI DSS within the next 6 to 12 months. "That may be a little late for some companies, but that is the data that we find, at the moment," Kark said. But just because an organization is currently PCI DSS compliant right now, does not mean that it will continue to be compliant indefinitely. Compliance to the PCI DSS rules will continue indefinitely, as new technologies and new ways of hacking personal data continue also. "In general, compliance is 100 percent, but it's a certain point in time, so if you are compliant today, it doesn't necessarily mean you will be compliant tomorrow," Kark said. "Being compliant means that at the time of the audit you [organization] were PCI compliant to 100 percent of the requirement in respect to whoever the auditor was…it's the auditor that makes the judgment, but it may not really remain 100 percent throughout."

PCI DSS: The Visa CISP Program:

For Visa, Inc., PCI DSS compliance includes following their Cardholder Information Security Program (CISP), along with the incorporated PCI DSS standards. The CISP program includes compliance and validation requirements for the following entities:

9

• Merchants-All merchants including retail (brick-and-mortar), mail/telephone order, and e-commerce.

• Service Providers-Visa identifies service providers as organizations that process, store, or transmit Visa cardholder data on behalf of Visa members, merchants, or other service providers.

• Payment Applications-Visa offers a "Best Practices" document for Payment applications, with the goal that the payment application must not retain full magnetic stripe data or CVV2 data. As well, as well the software must support a merchants and service providers' ability to comply with the PCI Data Security Standard.

MasterCard SDA Program:

For MasterCard Inc., compliance and validation includes following its Site Data Protection (SDA) Program, along with the incorporated PCI DSS standards. The SDA program includes compliance requirements for the following entities:

• Merchants-All merchants must become PCI DSS compliant through completing the PCI Self Assessment, PCI Onsite Assessment and PCI Quarterly Network Scanning. While all merchants are required to comply with the Payment Card Industry Data Security Standard, merchants that store, process or transmit MasterCard account data may also be required to validate compliance with their acquirer.

• Service Providers-Third Party Processors (TPPs), Data Storage Entities (DSEs). Any service providers that store, process or transmit MasterCard account data on behalf of the merchant must also be compliant.

• Vendors-Master Card provides a list of Approved Scanning Vendors (ASVs), based on the testing requirements laid out in the PCI DSS standard for ASVs.

• Acquirers-MasterCard works with acquirers to help the acquirer's merchants obtain SDA certification, as well as PCI DSS certification. The acquirer does not have to go through an SDA certification process, but the acquirer must manage the SDA process for their merchants. The acquirer must certify the merchants' compliance validation tools, as well as registering the merchant with MasterCard.

Defining PCI Compliance Merchant Validation Levels

In order to be PCI DSS compliant, each card issuer has its own criteria for assigning a merchant level and validation compliance classification level for a merchant, third party or service provider. The merchant level is based on transaction volume for the organization. The validation compliance level is based on the merchant level, and includes the validation actions and who needs to carry out the validation actions, in order to be PCI DSS compliant.

10

For the majority of organizations, the standards set forth by Visa's CISP program and MasterCard's SDP programs cover the qualifications for assigning both a merchant level and compliance level, along with incorporating PCI DSS. American Express and Discover, at this time, do not have a stringent program in place like Visa or MasterCard; however both companies have a 'best practices' document, which coincides with the PCI DSS. The current Visa and MasterCard merchant levels and changes from PCI DSS 1.0 to PCI DSS 1.1 are as follows:

• Level 1-Visa U.S.A. and MasterCard World Wide transactions totaling 6 million and up, per year, and any merchants who experienced a data breach.

• Level 2-Visa and MasterCard transactions totaling 1 million to 6 million per year. (The new requirement expands the number of Level 2 merchants to include former Level 4 merchants.)

• Level 3-Visa and MasterCard e-commerce transactions totaling 20,000 to 1 million per year. (The new requirement expands Level 3 to include former Level 2 merchants who process fewer than 1 million e-commerce transactions per year.)

• Level 4-Visa and MasterCard e-commerce transactions totaling up to 20,000 per year. (The new requirement decreases the number of Level 4 merchants.), and all other merchants, regardless of acceptance channel, processing up to 1 million Visa or MasterCard transactions per year.

The current Visa and MasterCard validation requirements are as follows:

• Level 1-Visa/MasterCard-- Annual onsite review by merchant's internal auditor or a Qualified Security Assessor (QSA) or Internal Audit if signed by Officer of the company, and a quarterly network security scan with an Approved Scanning Vendor (ASV).

• Level 2-- Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV.

• Level 3-- Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV.

• Level 4-- Completion of PCI DSS Self Assessment Questionnaire annually, and quarterly network security scan with an approved ASV. Submit summary of PCI compliance plan, via acquirer, by July 30, 2007. If a breach has been reported, or found, Visa reserves the right to move the Level 4 merchant to a Level 1. If so, the Level 4 merchant must abide by the Level 1 validation requirements. (See Level 4 Merchant Compliance for more information)

PCI DSS Level 4 Merchant Compliance

As PCI DSS continues to be enforced as the standard for credit card data security, the emphasis of compliance mandates have focused, primarily, on Level 1, Level 2 and Level 3 merchants.

11

On paper, this is the best and most obvious move, in order to protect the credit card data of the maximum number of cards and cardholders, and in order to emphasize-first-those merchants clearing the largest volume of transactions per year. But Level 4 merchants are now getting much more attention, as many of those merchants are now using integrated POS terminals connected to high speed Internet connections, instead of the usual stand alone, dial-up POS terminals, which cannot be accessed from the Internet. This disparity, along with the fact that Level 4 run the gamut between small mom-and-pop merchants, with one dial-up POS terminal, to huge brick-and-mortar operations with high speed lines, leaves some of these merchants wide open for hackers. According to Visa, Level 4 merchants handle fewer transactions than Levels 1,2 and 3, but they account for more than 99 percent of the merchants that accept Visa. This is an ultimate playground for hackers. "Usually, Level 4 merchants do not have the technical expertise, nor the IT Staff, to properly secure card holder data," said Aaron Biddar, President of ControlScan. "For all data breaches, you have two main risks: The internal risk-an employee obtaining a file that they shouldn't have, and an external risk-a hacker," he explained. "A hacker is going to look for the path of least resistance," he continued. "Level 1 and 2 merchants can afford to button up their IT infrastructure, because they have the money to do so; they can afford to staff a huge IT department, and they don't want to be a headline in the news." "So, if I am a hacker, I'm going to go to the merchant that I know cannot afford the proper security or staff to mitigate that type of breach," he finished. Biddar said that, even with the July deadline, Level 4 merchants and acquirers are becoming PCI compliant at a "trickle." Though Level 4 merchants are not required by the PCI SSC, or by card issuers such as Visa and MasterCard, to submit to an onsite security assessment, it's up to the acquirer to make sure that its Level 4 merchants understand the need for being PCI compliant. In order to spur this suggestion along, Visa, U.S.A., added a new, Level 4 Merchant Compliance Program in order to address data security issues for Level 4 merchants. The new program, released in May 2007, requires acquirers to develop and submit a formal written compliance plan to Visa, which "identifies, prioritizes and manages overall risk within their Level 4 merchant populations," according to the CISP Bulletin. Many acquirers have already developed, written and sent a summary of their plans to make their Level 4 merchants compliant, under Visa's PCI Compliance Acceleration Program (PCI CAP). (See Visa PCI CAP Program). But for those acquirers who have not written and/or sent a summary of their plan, one must be

12

emailed to Visa no later than July 31, 2007. Email summaries to cisp@visa.com. The Level 4 Merchant Compliance Program plan must consist of the following items:

• Timeline of Critical Events--Timeline of completion dates and milestones, for overall strategy.

• Risk-Profiling Strategy--Prioritization of Level 4 merchants into subgroups, from merchants that post the greatest risk, to those that post little risk at all. Factors such as merchant category transaction volume, market segment, acceptance channel, number of locations can help the acquirer target compliance efforts for each subgroup.

• Merchant Education Strategy--Strategy designed to eliminate prohibited data from being stored; protect stored data, and securing the environment in accordance with PCI DSS. This includes ensuring that merchants are only storing data they truly require, by complying with PCI DSS, and by making sure payment applications are compliant and any third-party agents are on Visa's list of CISP-Compliant Service Providers.

• Compliance Reporting--Monthly compliance reporting to executive or board management. Visa may also periodically request that the acquirer produce these reports.

Visa PCI CAP Program

Visa is the first credit card company to start a program that combines fines with incentives for acquirers to make their merchants PCI compliant, no matter the level. Visa has invested over $20 million dollars in order to pay Level 1 and Level 2 acquirers a one-time payment, for each merchant, if each Level 1 and Level 2 merchant is compliant by March 31, 2007. Acquirers whose Level 1 and Level 2 merchants validate compliance after March 31 and prior to August 31, 2007 will be eligible to receive a reduced one-time payment for each qualifying merchant. "Locking down cardholder data is an important security component that will benefit financial institutions and merchants, and is equally important to maintain consumer trust in Visa," said Michael E. Smith, senior vice president of Enterprise Risk and Compliance at Visa USA, in a Visa press release. "By combining both incentives and fines, we expect acquirers to increase their efforts with merchants to accelerate their progress toward becoming PCI compliant and eliminating the storage of sensitive card data. Nothing is more important to Visa than securing commerce." As well, under the CAP plan, acquirers are required to validate Level 1 and 2 merchant compliance with PIN security. This means that Level 1 and Level 2 merchants must not use payment devices such as PIN pads, and encourages the use of unique encryption keys for every device. For Level 3 and 4 merchants, acquirers must establish a thorough compliance program for those merchants. According to Visa, as of October 1, 2007, acquirers whose transactions qualify for lower

13

interchange rates available in the Visa and Interlink tiers must ensure that the merchants generating the transactions are PCI compliant in order to receive this benefit.

Defining Service Provider Validation Levels

In addition to merchants, PCI DSS validation requirements extend to service providers as well. According to Visa, service providers are defined as organizations that process, store, or transmit Visa cardholder data on behalf of Visa members, merchants, or other third parties. Card issuers and acquirers are responsible for making sure that their merchants utilize service providers that are compliant with the PCI DSS, even though there might not be a true contract between merchant service providers and acquirers. MasterCard defines a service provider as an encompassing term for Third Party Processors (TPPs) and Data Storage Entities (DSEs). According to the MasterCard Web site, Web merchants routinely contract with service providers to "facilitate many business functions, including, but not limited to, offering and selling their content online, payment services, hosting applications and processing." Visa and MasterCard service providers are responsible for any liability that may occur as a result of non-compliance. The current Service Provider Levels for Visa and MasterCard are as follows:

• Level 1 Visa - All VisaNet processors (member and Nonmember) and all payment gateways--agent or service provider that stores, processes, and/or transmits cardholder data as part of a payment transaction.

• Level 2 Visa - Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.

• Level 3 Visa - Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.

• Level 4 Visa - Merchants processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants-regardless of acceptance channel processing up to 1,000,000 Visa transactions per year.

• Level 1 MasterCard - All TPPs and DSE's that store account data on behalf of Level 1 or Level 2 merchants.

• Level 2 MasterCard - Includes all DSEs that store account data on behalf of level 3 merchants.

• Level 3 MasterCard - All other DSEs not included in Levels 1 and 2.

14

• Level 4 MasterCard - Any other merchant not covered in Level 1, Level 2 and Level 3 compliance qualifications.

The current Visa and MasterCard Service Provider Validation Requirements are as follows:

• Level 1 Visa - Annual On-Site PCI Data Security Assessment and Quarterly Network Scan, validated by a quality Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV).

• Level 2 Visa - Annual On-Site PCI Data Security Assessment and Quarterly Network Scan, validated by a quality QSA and ASV.

• Level 3 Visa -Annual PCI Self-Assessment Questionnaire, validated by the service provider and a Quarterly Network Scan, validated by a quality ASV.

• Level 1 MasterCard - Annual onsite review by merchant's internal auditor or a QSA, and a quarterly network security scan with an ASV.

• Level 2 MasterCard - Annual onsite review by merchant's internal auditor or a QSA, and a quarterly network security scan with an ASV.

• Level 3 MasterCard - Annual PCI Self-Assessment Questionnaire, validated by the service provider and a Quarterly Network Scan, validated by a quality ASV.

High Risk Merchant or Service Provider Any merchant or service provider, who continues to use non-compliant payment applications-applications that store magnetic strip, CVV or CVV2 and PIN data, is considered a High Risk. If a merchant or service provider is considered High Risk, they will be contacted by the acquirer and no matter the merchant or service provider compliance level, will be subject to an onsite review by an internal auditor or QSA. Competing Cards: American Express and Discover As stated earlier in this article, American Express and Discover Card, as of now, do not have actual guidelines or procedures in place, such as Visa and MasterCard have, however they do direct their merchants to follow PCI DSS standards. As a caveat within the CISP guidelines, Visa and MasterCard reserve the right to require merchants/service providers who process competing cards-most merchants process more than one credit card brand-to adhere to the CISP/PCI guidelines if Visa or MasterCard feels that the merchant has or is compromising credit card data in some way, that there is evidence of a previous hack or attack that compromised data, and if the competing card has transactions that equal a Level 1 merchant.

15

Acquirer PCI Compliance Responsibility

It's up to the specific acquirer, along with the issuing credit card company, to educate and enforce their merchants, vendors, service providers, or any entity that stores or processes credit card data, to comply and validate PCI DSS and CISP standards. If you are a merchant, vendor or service provider reading this information for the first time, it might be time-or past time-to question and contact your acquirer and credit card issuer. To take it one step further, in 2006, Visa levied $4.6 million in fines, up from a 2005 total of $3.4 million, to its acquirers. PCI DSS 1.1 sets an enforcement date for acquirers to validate PCI compliance for Level 1 and Level 2 merchants. The enforcement dates are as follows:

• Level 1 Merchants-Enforcement date: September 30, 2007

• New Level 1 Merchants-Enforcement date: One year after identification as Level 1

• Level 2 Merchants-Enforcement date: December 31, 2007

• New Level 2 Merchants-Enforcement date: September 20, 2007

• Level 1 and 2 Merchants-Prohibited Data Retention Attestation form, or Confirmation of Report Accuracy to acquirer by March 31, 2007

• Level 3 Merchants-Contact acquirer or Credit Card Company.

• Level 4 Merchants-Must have compliance plan submitted, via acquirer, to Visa by July 30, 2007.

For PCI compliance only, the acquirer will be fined between $5,000 dollars and $25,000 dollars per month for each Level 1 and Level 2 merchant who hasn't reached PCI compliance and PCI/CISP validation by September 30 and December 31, 2007. As of March 31, 2007, if an acquirer has a Level 1 or Level 2 merchant who is still retaining full-track data, Card Verification Value (CVV2) or PIN data after the transaction authorization, Visa can fine the acquirer up to $10,000 a month per merchant, if progress toward compliance is not made in a timely manner. According to the Visa Web site, Level 1 and 2 merchants must validate that prohibited data is not retained subsequent to authorization by submitting a completed Prohibited Data Retention Attestation form or Confirmation of Report Accuracy form to their acquirer by March 31, 2007.

16

Calculating Merchant Transactions for PCI DSS

According to the Visa, Inc. CISP Program Web site, merchants fall into one of the four merchant levels based on Visa transaction volume over a 12-month period. MasterCard's SDP is similar to Visa's CISP program. Gathering the correct numbers for transaction volume can be confusing, but for Visa, Inc., the merchant's transaction volume is based on the aggregate number of Visa transactions-credit cards, debit cards, prepaid cards-from a merchant Doing Business As ("DBA"). For merchants and/or merchant corporations who operate more than one DBA, the aggregate volume of stored, processed or transmitted transactions by the corporate entity must be considered, to determine the validation level. If the corporate entity does not store, process or transmit cardholder data on behalf of the multiple DBAs, members will continue to consider the DBA's individual transaction volume to determine the validation level. Confusing? Here is Kark's answer to the same question about how to calculate transactions for more than one merchant. "If an organization has several merchants, you have to aggregate all of those [merchant transaction] numbers, in order to come up with a number that you have in terms of the credit card data that resides within your organization, and the amount of transactions that you are processing within your organization," said Kark. Continuing, he said, "If you house credit card information, in whatever form, if you house it in your server, that you own or you added, then you are basically responsible for complying with PCI…merchants need to be added [to the transaction volume] if you are housing credit card information for the specific merchant."

PCI DSS: Visa and MasterCard Quick Reference Guide

Merchant, Service Provider and Compliance Level 1 Merchant Qualification Criteria for Visa and MasterCard:

• Retail and eCommerce Merchants with greater than 6 million Visa and MasterCard transactions annually.

• Merchants that have suffered a hack or an attack that resulted in an account data compromise.

• Merchants that Visa and MasterCard determines should meet the Level 1 merchant requirements to minimize risk to the Visa system, or merchants identified by any other payment card brand as Level 1.

17

Service Provider Qualification Criteria:

• Visa-All VisaNet processors (member and Nonmember) and all payment gateways--agent or service provider that stores, processes, and/or transmits cardholder data as part of a payment transaction.

• MasterCard-All TPPs and DSE's that store account data on behalf of Level 1 or Level 2 merchants.

Validation Requirement:

• Visa-- Annual onsite review by a QSA or Internal Audit if signed by Officer of the company, and a quarterly network security scan with an ASV.

• MasterCard-Annual onsite review by merchant's internal auditor or a Qualified Security Assessor (QSA), and a quarterly network security scan with an Approved Scanning Vendor (ASV).

Deadline: September 30, 2007 Merchant, Service Provider and Compliance Level 2 Merchant Qualification Criteria:

• E-Commerce merchants with 150,000 to 6 million Visa or MasterCard transactions annually.

• All merchants meeting the Level 2 criteria of a competing payment brand.

Service Provider Qualification Criteria:

• Visa--Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.

• MasterCard--Includes all those DSEs that store account data on behalf of level 3 merchants.

Validation Requirement:

• Visa-Annual onsite review by QSA and quarterly network security scan with an approved ASV.

• MasterCard-- Annual onsite review by QSA and quarterly network security scan with an approved ASV.

Deadline: December 31, 2007 Merchant and Service Provider Compliance Level 3 Merchant Qualification Criteria:

18

• Visa-Merchants with annual e-commerce transactions greater than 20,000 but less than one million total transactions.

• MasterCard-Merchants with annual e-commerce transactions greater than 20,000 but less than one million total transactions, and all merchants meeting the Level 3 criteria of a competing payment brand.

Service Provider Qualification Criteria:

• Visa- Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.

• MasterCard-All other DSEs not included in Levels 1 and 2.

Validation Requirement:

• Visa-Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV.

• MasterCard-Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV.

Deadline: Contact acquirer or card brand representative. Merchant and Service Provider Compliance Level 4 Merchant Qualification Criteria:

• Visa-Merchants processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants regardless of acceptance channel processing up to 1,000,000 Visa transactions per year. Completion of PCI DSS Self Assessment Questionnaire annually and quarterly network security scan with an approved ASV. Acquirer submits summary of PCI compliance plan to Visa by July 30, 2007. If a breach has been reported, or found, Visa reserves the right to move the Level 4 merchant to a Level 1. If so, the Level 4 merchant must abide by the Level 1 validation requirements. (See Level 4 Merchant Compliance for more information).

• MasterCard-Any other merchant not covered in Level 1, Level 2 and Level 3 compliance qualifications. " Validation Requirement:

• Visa--Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV. Complete a

• MasterCard-Completion of PCI DSS Self Assessment Questionnaire and quarterly network security scan with an approved ASV.

Deadline: Summary of PCI compliance plan, via acquirer, by July 30, 2007.

Step 3: Attaining PCI DSS Compliance - Merchant

Security Audits: 12 Requirements

19

The actual PCI Data Security Standards include 12 major requirements for validation and certification under six main auditing areas or "control objectives". All of the compliance areas include basic security rules that most merchants and service providers should already have in place, or have a familiarity with them when audited. If a merchant, Independent Sales Organization (ISO) or service provider is at a Level 1 or Level 2, one of the major PCI DSS validation components is the Annual On-Site PCI Data Security Assessment, which is based entirely from the PCI DSS Audit Procedures document. Merchants and service providers should select a Qualified Security Assessor (QSA) to perform the audit or-in the case of a Level 1 merchant or service provider-an internal audit, signed by the chief officer for the organization. Visa and MasterCard offer a list of approved QSAs on their Web site. These assessors should strictly adhere to the Audit Procedures document and complete the mandatory Report on Compliance required for PCI certification and validation on behalf of the merchant or service provider. According to the PCI Security Standards Council, all QSAs must attend a training class and pass an exam in order to have a basic knowledge and understanding of PCI DSS. PCI DSS consists of 12 key requirements:

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 the transmission of cardholder data across open, public networks. 5. Use and regularly update anti-virus software. 6. Develop and maintain secure systems and applications. 7. Restrict access to cardholder data. 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.

Compliance:

Visa requires you to comply with PCI DSS to help reduce your exposure to the reputation and financial risks associated with account payment data compromises. Your bank can help guide you through the relevant PCI DSS validation process.

However, if you do not comply with PCI DSS requirements, you could face financial or operational consequences—especially if you experience a breach and are found to be noncompliant.

The main control objectives for PCI DSS compliance and validation are as follows:

20

• Build and Maintain a Secure Network

• Protect Cardholder Data

• Maintain a Vulnerability Management Program

• Implement Strong Access Control Measures

• Regularly Monitor and Test Networks

Build and maintain a secure network:

In order to build and maintain a secure network, and to comply with the PCI DSS, system components, network components, and data elements related to authorization, data retention, data storage and data transmitting must be secure. This article gives a high level overview of the PCI DSS and is a brief overview of the audit checklist. Please refer to the PCI DSS documentation and the PCI Security Standards Web site for a detailed breakdown of all requirements. The scope of PCI DSS for Level 1 merchants includes the following areas:

• Cardholder Data-Primary Account Number, Cardholder Name, Service Code, Expiration Data, Full Magnetic Stripe, CVC2/CVV2/CID, PIN/PIN Block, including any data repository outside of the authorization environment, where more than 50,000 or more account numbers reside.

• System Components-Network components, servers or applications included or connected to cardholder data. Applications include all purchased and proprietary/custom applications, as well as internal and external Internet applications. (External connections into the merchant network like employee remote access, VisaNet and third party access for processing and maintenance).

• Network Components-Firewalls, switches, routers, wireless access points, network appliances and other security appliances. Server types include: Web, database, authentication, mail, proxy, network time protocol (NTP) and domain name server (DNS) (all connections to and from the authorization and settlement environment, such as connections for employee access or for devices such as firewalls and routers).

Point of Sale (POS) Environments POS needs its own category, because depending on the type of POS environment that exists for a merchant, that type will determine whether it needs to be included in the audit. If the POS environment is IP-based, along with having external access via the Internet, wireless device, Virtual Private Network (VPN), dial-up connection, broadband connection, or with accessible machines like kiosks to the merchant location, the POS environment is required to be in the scope of the on-site review.

21

If the POS environment is neither IP-based, nor does it have an external connection or access to the merchant location, then the on-site audit begins at the point of connection into the authorization and settlement environment. Wireless Environments According to the PCI DSS, Wireless environments and technologies are the least secure. The technologies are still considered fairly new, and caution is encouraged for any merchant or service provider who is considering using a wireless environment. The rules, according to version 1.1 of PCI DSS, are as follows:

• If wireless technology is used to store, process or transmit credit card data, Requirements and Testing Procedures for wireless environments apply and are mandatory.

• If a wireless local area network (LAN) is connected to, or is a part of the cardholder environment, Requirements and Testing Procedures for wireless environments apply and are mandatory.

• If a merchant wishes to use wireless technologies or environments, consider using wireless technologies for only non-sensitive data transmission.

Outsourcing and Service Providers For merchants that outsource storage, processing or transmission of credit card data to third party service providers, separate Report on Compliance documents must explain the role of each service provider. Conversely, all service providers are responsible for validating their own compliance with the PCI DSS requirements, independent of their customers' audits. Merchants and service providers must work together, producing a contract to submit to all associated third parties, which states that the third-party service providers will agree to follow the PCI DSS. Requirement 1: Install and maintain a firewall configuration to protect cardholder data

A firewall protects all traffic in and out of an organization's network, and it examines all network traffic, while blocking intrusive or unknown transmissions that do not meet the security criteria. According to PCI DSS, installing and maintaining a firewall that protects the merchant or service provider from unauthorized access from the Internet by Internet-based access through desktops, employee email accounts and/or e-commerce are key protection mechanisms for any computer network. Requirement 2: Don't use vendor-supplied defaults for system passwords and other security parameters This requirement is pretty self-explanatory, as vendor-supplied defaults for system passwords are easily hacked. In the world of the hacker, it's the first and easiest way to infiltrate a network system.

22

Though there are many other checkpoints for auditing purposes, the gist of this requirement is to always change vendor-supplied defaults before installing a system on the network (for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts). For wireless environments, the audit includes checking the vendor defaults, the wireless equivalent privacy (WEP) keys; default service set identifier (SSID), passwords and SNMP community strings. Requirement 3: Protect stored card holder data The basic tenet of Requirement 3 is to make sure that all sensitive cardholder data is unreadable, no matter where it is stored-portable media, backup media, logs, or wireless networks. As well, storing sensitive credit card data such as the full magnetic strip track data, CVV and CVV2 is prohibited under PCI DSS. However there is an exception to this rule. In instances where some of the data elements are needed from the magnetic stripe track data, storing the accountholders name, primary account number (PAN), expiration and service code is acceptable. At no time should a merchant or service provider store the card verification code or PIN verification data elements. Other methods of cardholder data protection include truncating cardholder data if full PAN is not needed, and not sending PAN in an unencrypted e-mail. Requirement 4: Encrypt transmission of cardholder data across open, public networks One of the major reasons TJX Companies, Inc. suffered the massive data breach that they did was due, in part, to faulty encryption security. TJX management believes that hackers were able to get their hands on the decryption software, rendering the network system hostage to the hackers' whims. If TJX had had a strong encryption program, the hackers could have gained access to the encrypted data, but they would not be able to read the data without the proper cryptographic keys. Confusion abounds concerning this requirement; however one of the most reliable encryption algorithms is AES-256. AES is the official encryption algorithm of the U.S. government, and information encrypted with it is considered secure until the year 2030. AES offers 128, 196 and 256 key lengths, making it very secure. Data stored with AES cannot be decrypted without the key. A QSA assessor can research and decide on the effectiveness of AES and/or other algorithms.

23

Requirement 5: Use and regularly update anti-virus software Across the board, whether merchant, service provider, or average citizen, up-to-date anti-virus software can protect systems from viruses and malicious intrusions. The three main points of this requirement are:

• Deploy anti-virus software on all systems commonly affected by viruses-Personal computers and servers.

• Ensure that anti-virus programs are capable of detecting, removing, and protecting against other forms of malicious software, including spy ware and adware.

• Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs.

Requirement 6: Develop and maintain secure systems and applications Continuously updated, vendor-provided security patches and software patches can stop hackers from gaining access to network systems. Attacks can come from not only hackers, but also employees and viruses. The following PCI DSS requisites represent a sample of Requirement 6:

• All systems must have the most recently released appropriate software patches to protect against exploitation by employees, external hackers, and viruses.

• Implement a process to identify newly discovered security vulnerabilities-Subscribe to alert services on the Internet, or via anti-virus software.

• Develop software applications based on industry best practices-Visa's Payment Application Best Practices (PABP), for payment applications.

• Test all security patches system and software configurations before deployment. • Removal of custom application accounts, usernames and passwords before

applications become active or are released to customers. • Review of custom code prior to release to production or customers in order to

identify any potential coding vulnerability.

Requirement 7: Restrict to cardholder data by business need to know One of the most common, yet overlooked, vulnerability for any organization and for the systems within that organization, is a lax access control policy. Many organizations still allow employees, with no direct connection with the data, to view sensitive cardholder data or to access network systems. In order to adhere to Requirement 7, a merchant or service provider must do the following:

24

• Computing resources and cardholder information-Limit access to employees whose job requires that they have access to the data.

• Implement a "deny all" mechanism-For systems with multiple users, put in place a mechanism that automatically denies any employee who is not authorized to view the data.

Requirement 8: Assign a unique ID to each person with computer access In order to comply with PCI DSS, each computer user in your organization should be assigned a unique ID, before you allow the user to access your system and the cardholder data stored within your system. The following PCI DSS requisites represent a sample of Requirement 8:

• Employ either a password, token devices, or Biometrics. • Use remote authentication, dial-in service, terminal access, controller access,

controller system (TCACS) with tokens, or VPN with individual certificates for employees, administrators and third parties.

• Encrypt all passwords during transmission and storage on all system components.

Requirement 9: Restrict physical access to Cardholder data The lack of enforcing restrictions on an employee's physical proximity to sensitive data, such as credit card data, continues to be a very common and basic violation. This requirement forces organizations to apply rules on access and proximity to the actual credit card data, and it develops procedures to identify employees and visitors. The following PCI DSS requisites represent a sample of Requirement 9:

• Restrict physical access to wireless access points, gateways and handheld devices. • Restrict physical access to publicly accessible network jacks. • Store media back-ups in a secure location, preferably an off-site facility. • Physically secure all paper and electronic media-computers, electronic media,

networking and communications.

Requirement 10: Track and monitor access to network resources and Cardholder data The use of logging mechanisms and audit trials allow an organization to track user activities. According to the PCI DSS, having the ability to log and track helps to determine where a problem occurred. The following PCI DSS requisites represent a sample of Requirement 10:

• Establish a process for linking all access to system components to each individual user.

25

• Implement automated audit trails for all system components, with administrative privileges to each individual.

• Secure audit trails so they cannot be altered. • Limit viewing of audit trails to those with a job-related need. • Promptly back up audit trail files to a centralized log server or media that is difficult to

alter.

Requirement 11: Regularly test security systems and processes Without continual testing of the security systems in place, hackers can capitalize on system-wide vulnerabilities within processes and custom software. The following PCI DSS requisites represent a sample of Requirement 11:

• Quarterly Security Testing-Test all security controls, network connections and restrictions annually, and use a wireless analyzer at least quarterly to identify all wireless devices in use.

• Quarterly Vulnerability Scans-Run internal and external network vulnerability scans quarterly, especially after any change in the network.

• Penetration Testing-Once a year, perform penetration testing, especially after an operation system upgrade, a sub-network added to the environment, or a web server added to the environment.

Requirement 12: Maintain a policy that addresses information security One of the most basic tools to combat a security breach is an actual written policy for all employees in the organization. As the PCI DSS states, "A strong security policy sets the security tone for the whole company and informs the employees what is expected of them." The following PCI DSS requisites represent a sample of Requirement 12:

• Establish, publish, maintain, and disseminate a security policy that addresses all of the requirements in the specifications.

• Develop daily operational security procedures that are consistent with requirements in this specification.

• Develop usage polices for critical employee-facing technologies to define proper use of these technologies for all employees and contractors.

• Prohibit cardholder data storage onto local hard drives, floppy disks, or other external media, when accessing cardholder data remotely via a modem.

Step 4: Finding a PCI DSS Approved Scanning Vendor (ASV)

Do You Need an ASV?

26

In order to meet the quarterly network scanning requirements, merchants and service providers with a Level of 1, 2, 3, 4, need an ASV to facilitate the scanning. Any merchant or service provider with annual transactions totaling 10,000 or more is required to have a quarterly network system scan. According to the PCI Security Standards Council, the MasterCard ASV program was terminated on or about October 7, 2006, and Visa International's QSA certification program transitioned from October to December 2006 to revert to the PCI SSC's guidelines and ASV lists. Currently, the PCI Security Standards Council administers all ASV contracts, and the PCI SSC also trains and certifies ASVs. All scans must be conducted by an ASV and are required to conduct scans in accordance with the "Technical and Operational Requirements for Approved Scanning Vendors (ASVs)" procedures. The main points of the technical and operational requirements for ASVs are as follows:

• The normal customer environment is not to be impacted. • The ASV should never penetrate or alter the customer environment.

PCI DSS: Security Scanning Procedures

Merchant and Service Provider Scanning Requirements PCI Security Scans provide merchants and service providers with invaluable information concerning their network system and work hand-in-hand with a comprehensive vulnerability management program. PCI approved scans can help a merchant or service provider find misconfigurations of Web sites, applications and IT infrastructures with Internet-facing IP addresses The results of a PCI approved scan can provide knowledge that can lead to efficient patch management and other security measures that can rectify problems and improve protection against future Internet attacks. The following is an overview of the basic scanning requirements for merchants, service providers and ASVs:

• Internet-facing IP Addresses--Merchants and service providers must scan their web sites or IT infrastructures that have externally facing IP addresses. If active IP addresses are found that were not originally provided by the customer, the ASV must consult with the customer to determine if these IP addresses should be in scope. If an account data compromise occurs via an IP address or component not included in the scan, the merchant or service provider is responsible.

27

• Domain-based virtual hosting-- Provide the ASV with a list of all domains that should be scanned if domain-based virtual hosting is used.

• Defining the scope of the scan-If an organization has a large number of IP addresses, but they only use a small number for card acceptance or processing, the ASV can help the merchant or service provider define the scope of the network scan.

• Applying segmentation-To reduce the scope of the network scan, an ASV can actually help the merchant or service provider segment the IP addresses in one of two ways: (1) by providing physical segmentation between the segment handling cardholder data and other segments, and (2) by employing appropriate logical segmentation where traffic is prohibited.

• Filtering devices-- The ASV must scan all filtering devices such as firewalls or external routers (if used to filter traffic). Firewalls and routers, used to establish a demilitarized zone (DMZ) must also be scanned for vulnerabilities.

• Web Servers-Internet users view Web pages, and/or buy merchandise through Web merchants via a Web server. Because these servers are fully accessible from the public Internet, scanning for vulnerabilities is essential.

• Application Servers-When a cardholder sends account numbers in a transaction with a merchant or service provider, the application server is the actual interface that allows data to be transferred in and out of a network via backend databases. The ASV must scan application servers, or the Web server itself, when it's configured to act as an application server.

• Domain Name Servers (DNS)-The DNS server is the server that translates domain names into IP addresses. A merchant or service provider either uses the DNS provided by an Internet Service Provider (ISP), or their own DNS. Either way, an AVS must scan all DNSs, because hackers can create a fake merchant or service provider Web site, and ask for and collect credit card data fraudulently on behalf of the organization.

• Mail Servers-ASVs must scan mail servers, as mail servers are routinely vulnerable to hacker attacks.

• Scan all Load Balancers-If merchants or service providers use a load balancer to spread the traffic load to more than one server, then they should scan all of the individual servers behind the load balancer.

• Virtual Hosts-If a merchant or service provider shares a server through a Web hosting company, then they are also sharing that server with the other customers of that Web hosting company. It's the merchant or service provider's responsibility to request that their hosting company provide a scan of their entire Internet-facing IP

28

range and demonstrate compliance, while the merchant or service providers are required to have their own domains scanned by an ASV.

• Wireless Access Points-Wireless LANs (WLANs) set up data security risks-like misconfigurations-that need to be identified and resolved. The ASV must scan wireless access points in wireless LANs (WLANs), along with other wireless components that are connected to the Internet.

• Intrusion detection and prevention-Merchants and service providers must configure the intrusion detection system/intrusion prevention system (IDS/IPS) to accept the originating IP address of the ASV. If this is not feasible, the scan should originate in a location that prevents IDS/IPS interference.

Vulnerability Levels

Based on the results of the network scan, ASVs produce an exhaustive report that describes the following:

• Vulnerability type or risk • Diagnosis of issues linked to the vulnerability type • Consult on how to fix or patch the isolated vulnerabilities • Assign a rating for vulnerabilities

Each ASV may have a distinctive method of reporting vulnerabilities, but all high-level risks will be reported consistently to ensure a fair and consistent compliance rating. In order to be PCI DSS compliant, or compliant with any card brand program, a scan must not contain any vulnerability concerning features or configurations that are a PCI DSS violation. If the ASV determines that these exist, the ASV meets with the merchant or service provider to determine if these are really PCI DSS violations. If so, the ASV issues a noncompliant scan report. High-level vulnerabilities are designated as level 3, 4, or 5. Level 5 Vulnerabilities

Level 5 (Urgent) -With this level of vulnerability, hackers can compromise the entire host. This vulnerability type allows hackers to have complete access to full file-system read and write capabilities, remote execution of commands as a root or administrator user, as well as the presence of backdoors and Trojans. Level 4 Vulnerabilities Level 4 (Critical) -Gives hackers partial access to file-systems and also provides them with remote user capabilities. These vulnerabilities expose highly sensitive information.

29

Level 3 Vulnerabilities Level 3 (High) -Gives hackers access to information stored on the host, including security settings. It sets up misuse of the host by intruders. Examples include access to specific files, denial of service attacks, directory browsing, mail relaying.

Level 2 Vulnerabilities Level 2 (Medium) -Gives hackers a chance to research attacks against the host, and access to some sensitive information from the host, such as exact versions of services. Level 1 Vulnerabilities Level 1 (Low) --Vulnerabilities expose information, such as open ports. Information can be obtained by hackers on configuration.

Compliance Reporting

Though the PCI SSC has assumed ownership and management of Visa and MasterCard's compliance reporting programs, it's still incumbent upon merchants and service providers to follow each card company's compliance reporting requirements, to ensure that the card company accepts and verifies their compliance status. Compliance reports must be submitted according to each card's requirements. According to the PCI SCC, payment brands-MasterCard, Visa, American Express, and Discover-will continue to focus on compliance of the security standards. "Any entity that achieves PCI DSS compliance will need to continue sending the appropriate compliance validation documentation to the payment brands, financial institutes, or other agents that have a contractual relationship with the compliant entity," According to the PCI SSC FAQ. "PCI SSC cannot be the central repository for this information. Our focus will remain on defining effective payment-related security standards, as well as educating and providing resources to the marketplace to drive awareness and adoption of these standards." Qualified Security Assessors (QSA)

As with the ASVs, the Qualified Security Assessors (QSAs) conduct PCI validation assessments compliant with the PCI DSS. The skill level and competence of a QSA must meet the PCI SSC standards. Individual QSAs, who perform PCI Data Security Assessments for merchants and service providers must be approved as a Qualified Security Assessor ("QSA") by the PCI SSC. The PCI SSC defines the qualifications for QSAs and ASVs, as well as training, testing and certifying

30

both. The PCI SSC Web sites, and the Visa and MasterCard Web sites, post the lists of qualified QSAs.

Visa and Compliance Reporting

Level 1 Merchants According to the Visa Web site, the template for the Report on Compliance is the actual Annual On-Site PCI Data Security Assessment document. In order to complete the Report on Compliance, Level 1 merchants need a Qualified Security Assessor (QSA) to complete the Report on Compliance and present the report to the merchant/service provider's acquirer. A merchant's acquirer may choose to accept the Report on Compliance from a Level 1 merchant, with a letter signed by a merchant officer within the organization, along with the report. Level 1 merchants must also submit the Confirmation of Report Accuracy form completed by their QSA to their acquirers. Once the acquirer accepts the information, the acquirer must submit the Confirmation of Report Accuracy form and a letter accepting the merchant's full compliance validation to Visa upon receipt and acceptance of the merchant's validation documentation. Level 1, 2 and 3 Merchants According to the Visa Web site, acquirers are responsible for ensuring that the quarterly network security scans required of their levels 1, 2, and 3 merchants are performed by an ASV. The Quarterly Network Security Scan may be required of level 4 merchants as specified by their acquirer. Level 2 and Level 3 Merchants Level 2 and 3 merchants must complete the Annual PCI Self-Assessment Questionnaire. Level 4 merchants may be required to complete the PCI Self-Assessment Questionnaire as specified by their acquirer. Level 1 and Level 2 Service Providers Level 1 and 2 service providers must complete the Annual Self-Assessment Questionnaire and Annual On-Site PCI Data Security Assessment. The results from both must be supplied to the acquirer, and the documents may serve as the template for the Report on Compliance. Levels 1 and 2 service providers must employ a (QSA) to complete the Report on Compliance. Level 1, 2 and 3 Service Providers Level 1, 2, and 3 service providers are accountable for ensuring that an ASV performs a quarterly network scan on the Internet-facing network perimeter systems. Level 3 Service Providers Level 3 service providers must complete the Annual PCI Self-Assessment Questionnaire.

31

MasterCard and Compliance Reporting

Level 1 Merchants For the annual onsite review, MasterCard allows the review to be conducted by either the merchant's internal auditor or a QSA. Level 1, 2, 3 and 4 Merchants To fulfill the network-scanning requirement, all merchants must conduct scans on a quarterly basis using an Approved Scanning Vendor. Level 4 Merchants Level 4 Merchants should consult their acquirer to determine if compliance validation is also required. Level 1 and 2 Service Providers For the annual onsite review, MasterCard Service Providers must use a QSA. Level 1, 2 and 3 Service Providers For the quarterly network-scanning requirement, all Level 1, 2 and 3 service providers must use an AVS. MasterCard SDP Compliance Along with following PCI DSS, MasterCard merchants must follow these steps:

• Associate the level classification in the SDP Program. • Go through the PCI documentation and compliance validation tools. • Make contact with an approved vendor, if needed, and follow the compliance

procedures. • Validate compliance with acquirer--the acquirer will register you with MasterCard on

an annual basis, signifying compliance with the SDP Program.

Step 5: Completing the PCI DSS Self Questionnaire

For Level 2, 3 and-in some instances-Level 4 merchants and service providers, responding to the PCI Self Questionnaire is one validation requirement that must be met. It is divided into six sections based on the 12 PCI DSS requirements. It serves as somewhat of a checklist, to make certain that a merchant has completed the PCI DSS security steps to protect credit card data. The questionnaire identifies any area of non-compliance. Preparing to Answer In order to properly answer the questionnaire, make sure to read and review the PCI Data Security

32

Standard. If, after going through the PCI DSS documents, your organization already meets the PCI SSC requirements, do the following:

• Fill out the PCI Self Questionnaire. • Convert the questionnaire to a PDF file. • Send the document to your acquiring bank.

If your organization does not meet the PCI SSC requirements stated in the questionnaire, do the following:

• Print and distribute the questionnaire to the appropriate authorities within your organization to obtain accurate answers.

• Take the steps necessary to establish a set of correct answers. • Complete the questionnaire.

Scoring the Questionnaire

In order to send a valid PCI Self Assessment Questionnaire, merchants/service providers have to answer all of the questions with a 'Yes' or 'N/A' in order to be compliant per the PCI DSS. If a merchant/service provider answers 'No' to any question, the organization is deemed 'Non Compliant.' The security threat areas identified by the questionnaire must be resolved, in conjunction with recommendations from the selected ASV or QSA. Organizations must continue to retake the questionnaire, until all questions can be answered with a 'Yes' or 'N/A.' Step 5: Sending the PCI DSS Questionnaire Once the requirements have been met and the questionnaire has been completed, it should be sent to the merchant's acquiring bank alongside a successful PCI scan report from an approved scanning vendor. As well, if the organization's acquirer or credit card brand requires other certifying documentation in addition to the questionnaire, those accompanying documents must be sent to the acquirer. Please check with your acquirer or credit card company for more information.

Source: www.pcicomplianceguide.org

33

Cardholder Data Theft and Fraud – real life cases • February 18, 2005 – Bank of America claimed that it had lost more than 1.2 million customer records – though it said there was no evidence that the data had fallen into the hands of criminals. • June 16, 2005 – CardSystems, a merchant payment-processing provider, was sued in a series of class action cases alleging that it failed to adequately protect the personal information of 40 million customers. CardSystems’ business faced collapse as VISA and American Express cut their ties with the company, prohibiting it from processing their card data. CardSystems was subsequently acquired by another company. • February 9, 2006 – It was estimated that around 200,000 debit card accounts were disclosed by unknown retail merchants, apparently OfficeMax and others. These included accounts related to bank and credit union acquirers nationwide such as Citibank and Wells Fargo. • January 31, 2006 – Boston Globe and The Worcester Telegram & Gazette unwittingly exposed 240,000 credit and debit card records along with routing information for personal checks printed on recycled paper used in wrapping newspaper bundles for distribution. • January 12, 2007 – MoneyGram, a payment service provider, reported that a company server was unlawfully accessed over the Internet last month. It contained information on about 79,000 bill payment customers, including names, addresses, phone numbers, and in some cases, bank account numbers. • January 17, 2007 – TJX Companies Inc. publicly disclosed that they had experienced an unauthorized intrusion into the electronic credit/debit card processing system. In what is considered the most glamorous security breaches to date, as much as 45,700,000 credit/debit card account numbers and over 455,000 merchandise return records (containing customer names and driver's license numbers) were stolen from the company’s IT system.

Source: “PCI DSS made easy” from ittoolbox.com