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
1
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
2
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
3
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.
4
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:
5
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.
6
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
7
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:
8
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.
9
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.
10
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
11
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
12
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.
13
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.
14
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.
15
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.
16
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:
17
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
18
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:
19
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.
20
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.
21
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.
22
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:
23
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.
24
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?
25
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.
26
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
27
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.
28
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
29
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.
30
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
31
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
32
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
33