SlideShare a Scribd company logo
1 of 33
Download to read offline
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
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
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
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
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
•   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
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
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
•   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
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
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
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
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
•   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
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
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
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
•    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
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
•    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
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
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
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
•   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
•   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
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
•   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
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
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
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
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
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
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

More Related Content

What's hot

Senate_2014_Data_Breach_Testimony_Richey
Senate_2014_Data_Breach_Testimony_RicheySenate_2014_Data_Breach_Testimony_Richey
Senate_2014_Data_Breach_Testimony_RicheyPeter Tran
 
The Smart Approach To Pci DSS Compliance – Braintree White Paper
The Smart Approach To Pci DSS Compliance – Braintree White PaperThe Smart Approach To Pci DSS Compliance – Braintree White Paper
The Smart Approach To Pci DSS Compliance – Braintree White PaperBen Rothke
 
Payment Card Industry Introduction CMTA APR 2010
Payment Card Industry Introduction CMTA APR 2010Payment Card Industry Introduction CMTA APR 2010
Payment Card Industry Introduction CMTA APR 2010Donald E. Hester
 
eCommerce Summit Atlanta Mountain Media
eCommerce Summit Atlanta Mountain MediaeCommerce Summit Atlanta Mountain Media
eCommerce Summit Atlanta Mountain MediaeCommerce Merchants
 
Online_Transactions_PCI
Online_Transactions_PCIOnline_Transactions_PCI
Online_Transactions_PCIKelly Lam
 
PCI_Presentation_OASIS
PCI_Presentation_OASISPCI_Presentation_OASIS
PCI_Presentation_OASISDermot Clarke
 
Reducing cardholder data footprint with tokenization and other techniques
Reducing cardholder data footprint with tokenization and other techniquesReducing cardholder data footprint with tokenization and other techniques
Reducing cardholder data footprint with tokenization and other techniquesVISTA InfoSec
 
Acc 675 control audit final project
Acc 675 control audit final projectAcc 675 control audit final project
Acc 675 control audit final projectKelly Giambra
 
Verizon 2014 pci compliance report
Verizon 2014 pci compliance reportVerizon 2014 pci compliance report
Verizon 2014 pci compliance reportBee_Ware
 
Verizon 2014 PCI Compliance Report
Verizon 2014 PCI Compliance ReportVerizon 2014 PCI Compliance Report
Verizon 2014 PCI Compliance Report- Mark - Fullbright
 
PCI Compliance for Community Colleges @One CISOA 2011
PCI Compliance for Community Colleges @One CISOA 2011PCI Compliance for Community Colleges @One CISOA 2011
PCI Compliance for Community Colleges @One CISOA 2011Donald E. Hester
 
Payment Card Industry CMTA NOV 2010
Payment Card Industry CMTA NOV 2010Payment Card Industry CMTA NOV 2010
Payment Card Industry CMTA NOV 2010Donald E. Hester
 
PCI Compliance - How To Keep Your Business Safe From Credit Card Criminals
PCI Compliance - How To Keep Your Business Safe From Credit Card CriminalsPCI Compliance - How To Keep Your Business Safe From Credit Card Criminals
PCI Compliance - How To Keep Your Business Safe From Credit Card CriminalsFit Small Business
 
Data Security: A field guide for franchisors
Data Security: A field guide for franchisorsData Security: A field guide for franchisors
Data Security: A field guide for franchisorsGrant Thornton LLP
 
The Path to Payment Security
The Path to Payment SecurityThe Path to Payment Security
The Path to Payment SecurityTom Cooley
 
Chapter 10 aml technologies
Chapter 10   aml technologiesChapter 10   aml technologies
Chapter 10 aml technologiesQuan Risk
 

What's hot (20)

Senate_2014_Data_Breach_Testimony_Richey
Senate_2014_Data_Breach_Testimony_RicheySenate_2014_Data_Breach_Testimony_Richey
Senate_2014_Data_Breach_Testimony_Richey
 
Requirement of PCI DSS in India.
Requirement of PCI DSS in India.Requirement of PCI DSS in India.
Requirement of PCI DSS in India.
 
The Smart Approach To Pci DSS Compliance – Braintree White Paper
The Smart Approach To Pci DSS Compliance – Braintree White PaperThe Smart Approach To Pci DSS Compliance – Braintree White Paper
The Smart Approach To Pci DSS Compliance – Braintree White Paper
 
Payment Card Industry Introduction CMTA APR 2010
Payment Card Industry Introduction CMTA APR 2010Payment Card Industry Introduction CMTA APR 2010
Payment Card Industry Introduction CMTA APR 2010
 
PCI-DSS for IDRBT
PCI-DSS for IDRBTPCI-DSS for IDRBT
PCI-DSS for IDRBT
 
eCommerce Summit Atlanta Mountain Media
eCommerce Summit Atlanta Mountain MediaeCommerce Summit Atlanta Mountain Media
eCommerce Summit Atlanta Mountain Media
 
Online_Transactions_PCI
Online_Transactions_PCIOnline_Transactions_PCI
Online_Transactions_PCI
 
PCI_Presentation_OASIS
PCI_Presentation_OASISPCI_Presentation_OASIS
PCI_Presentation_OASIS
 
Reducing cardholder data footprint with tokenization and other techniques
Reducing cardholder data footprint with tokenization and other techniquesReducing cardholder data footprint with tokenization and other techniques
Reducing cardholder data footprint with tokenization and other techniques
 
Acc 675 control audit final project
Acc 675 control audit final projectAcc 675 control audit final project
Acc 675 control audit final project
 
Verizon 2014 pci compliance report
Verizon 2014 pci compliance reportVerizon 2014 pci compliance report
Verizon 2014 pci compliance report
 
Verizon 2014 PCI Compliance Report
Verizon 2014 PCI Compliance ReportVerizon 2014 PCI Compliance Report
Verizon 2014 PCI Compliance Report
 
Community Bank Jun2015
Community Bank Jun2015Community Bank Jun2015
Community Bank Jun2015
 
PCI Compliance for Community Colleges @One CISOA 2011
PCI Compliance for Community Colleges @One CISOA 2011PCI Compliance for Community Colleges @One CISOA 2011
PCI Compliance for Community Colleges @One CISOA 2011
 
Payment Card Industry CMTA NOV 2010
Payment Card Industry CMTA NOV 2010Payment Card Industry CMTA NOV 2010
Payment Card Industry CMTA NOV 2010
 
PCI Compliance - How To Keep Your Business Safe From Credit Card Criminals
PCI Compliance - How To Keep Your Business Safe From Credit Card CriminalsPCI Compliance - How To Keep Your Business Safe From Credit Card Criminals
PCI Compliance - How To Keep Your Business Safe From Credit Card Criminals
 
Data Security: A field guide for franchisors
Data Security: A field guide for franchisorsData Security: A field guide for franchisors
Data Security: A field guide for franchisors
 
PCI DSS: Why it matters
PCI DSS: Why it mattersPCI DSS: Why it matters
PCI DSS: Why it matters
 
The Path to Payment Security
The Path to Payment SecurityThe Path to Payment Security
The Path to Payment Security
 
Chapter 10 aml technologies
Chapter 10   aml technologiesChapter 10   aml technologies
Chapter 10 aml technologies
 

Similar to Payment card industry data security standard 1

Payment card industry data security standard
Payment card industry data security standardPayment card industry data security standard
Payment card industry data security standardsallychiu
 
Pci compliance
Pci compliancePci compliance
Pci compliancepcihghg23
 
PCI DSS Slidecast
PCI DSS SlidecastPCI DSS Slidecast
PCI DSS SlidecastRobertXia
 
Tripwire pci basics_wp
Tripwire pci basics_wpTripwire pci basics_wp
Tripwire pci basics_wpEdward Lam
 
Nt1310 Project Design
Nt1310 Project DesignNt1310 Project Design
Nt1310 Project DesignErin Adams
 
Essay On Final Project
Essay On Final ProjectEssay On Final Project
Essay On Final ProjectPawpaw Tran
 
Understanding Your PCI DSS Guidelines: Successes and Failures
Understanding Your PCI DSS Guidelines: Successes and FailuresUnderstanding Your PCI DSS Guidelines: Successes and Failures
Understanding Your PCI DSS Guidelines: Successes and Failures- Mark - Fullbright
 
PCI FAQs and Myths - BluePay
PCI FAQs and Myths - BluePayPCI FAQs and Myths - BluePay
PCI FAQs and Myths - BluePayBluePayProcessing
 
PCI DSS Data Security Compliance Program Overview
PCI DSS Data Security Compliance Program OverviewPCI DSS Data Security Compliance Program Overview
PCI DSS Data Security Compliance Program Overview- Mark - Fullbright
 
Quick Reference Guide to the PCI Data Security Standard
Quick Reference Guide to the PCI Data Security StandardQuick Reference Guide to the PCI Data Security Standard
Quick Reference Guide to the PCI Data Security Standard- Mark - Fullbright
 
Is your business PCI DSS compliant? You’re digging your own grave if not
Is your business PCI DSS compliant? You’re digging your own grave if notIs your business PCI DSS compliant? You’re digging your own grave if not
Is your business PCI DSS compliant? You’re digging your own grave if notCheapSSLsecurity
 
PCI DSS introduction by khaled mosharraf,
PCI DSS introduction by khaled mosharraf,PCI DSS introduction by khaled mosharraf,
PCI DSS introduction by khaled mosharraf,Khaled Mosharraf
 
Payment Card Industry Introduction 2010
Payment Card Industry Introduction 2010Payment Card Industry Introduction 2010
Payment Card Industry Introduction 2010Donald E. Hester
 

Similar to Payment card industry data security standard 1 (20)

Payment card industry data security standard
Payment card industry data security standardPayment card industry data security standard
Payment card industry data security standard
 
Pci compliance
Pci compliancePci compliance
Pci compliance
 
PCI DSS Slidecast
PCI DSS SlidecastPCI DSS Slidecast
PCI DSS Slidecast
 
PCI FAQs and Myths
PCI FAQs and MythsPCI FAQs and Myths
PCI FAQs and Myths
 
Tripwire pci basics_wp
Tripwire pci basics_wpTripwire pci basics_wp
Tripwire pci basics_wp
 
Pci ssc quick reference guide
Pci ssc quick reference guidePci ssc quick reference guide
Pci ssc quick reference guide
 
PCI DSS
PCI DSSPCI DSS
PCI DSS
 
Nt1310 Project Design
Nt1310 Project DesignNt1310 Project Design
Nt1310 Project Design
 
Essay On Final Project
Essay On Final ProjectEssay On Final Project
Essay On Final Project
 
Understanding Your PCI DSS Guidelines: Successes and Failures
Understanding Your PCI DSS Guidelines: Successes and FailuresUnderstanding Your PCI DSS Guidelines: Successes and Failures
Understanding Your PCI DSS Guidelines: Successes and Failures
 
PCI FAQs and Myths - BluePay
PCI FAQs and Myths - BluePayPCI FAQs and Myths - BluePay
PCI FAQs and Myths - BluePay
 
PruebaJLF.pptx
PruebaJLF.pptxPruebaJLF.pptx
PruebaJLF.pptx
 
Pcidss qr gv3_1
Pcidss qr gv3_1Pcidss qr gv3_1
Pcidss qr gv3_1
 
PCI DSS Data Security Compliance Program Overview
PCI DSS Data Security Compliance Program OverviewPCI DSS Data Security Compliance Program Overview
PCI DSS Data Security Compliance Program Overview
 
Quick Reference Guide to the PCI Data Security Standard
Quick Reference Guide to the PCI Data Security StandardQuick Reference Guide to the PCI Data Security Standard
Quick Reference Guide to the PCI Data Security Standard
 
Evolution Pci For Pod1
Evolution Pci For Pod1Evolution Pci For Pod1
Evolution Pci For Pod1
 
What Everybody Ought to Know About PCI DSS and PA-DSS
What Everybody Ought to Know About PCI DSS and PA-DSSWhat Everybody Ought to Know About PCI DSS and PA-DSS
What Everybody Ought to Know About PCI DSS and PA-DSS
 
Is your business PCI DSS compliant? You’re digging your own grave if not
Is your business PCI DSS compliant? You’re digging your own grave if notIs your business PCI DSS compliant? You’re digging your own grave if not
Is your business PCI DSS compliant? You’re digging your own grave if not
 
PCI DSS introduction by khaled mosharraf,
PCI DSS introduction by khaled mosharraf,PCI DSS introduction by khaled mosharraf,
PCI DSS introduction by khaled mosharraf,
 
Payment Card Industry Introduction 2010
Payment Card Industry Introduction 2010Payment Card Industry Introduction 2010
Payment Card Industry Introduction 2010
 

More from wardell henley

RP_Patch_Management_S508C.pdf
RP_Patch_Management_S508C.pdfRP_Patch_Management_S508C.pdf
RP_Patch_Management_S508C.pdfwardell henley
 
Landscape_Medicaid_Healthcare_Information_Technology.pdf
Landscape_Medicaid_Healthcare_Information_Technology.pdfLandscape_Medicaid_Healthcare_Information_Technology.pdf
Landscape_Medicaid_Healthcare_Information_Technology.pdfwardell henley
 
Facets Overview and Navigation User Guide.pdf
Facets Overview and Navigation User Guide.pdfFacets Overview and Navigation User Guide.pdf
Facets Overview and Navigation User Guide.pdfwardell henley
 
self_inspect_handbook_nisp.pdf
self_inspect_handbook_nisp.pdfself_inspect_handbook_nisp.pdf
self_inspect_handbook_nisp.pdfwardell henley
 
Itil a guide to cab meetings pdf
Itil a guide to cab meetings pdfItil a guide to cab meetings pdf
Itil a guide to cab meetings pdfwardell henley
 
9 150928065812-lva1-app6892 gmp
9 150928065812-lva1-app6892 gmp9 150928065812-lva1-app6892 gmp
9 150928065812-lva1-app6892 gmpwardell henley
 
15466 mba technology_white_paper
15466 mba technology_white_paper15466 mba technology_white_paper
15466 mba technology_white_paperwardell henley
 
Best practices for_implementing_security_awareness_training
Best practices for_implementing_security_awareness_trainingBest practices for_implementing_security_awareness_training
Best practices for_implementing_security_awareness_trainingwardell henley
 
213946 dmarc-architecture-identifier-alignmen
213946 dmarc-architecture-identifier-alignmen213946 dmarc-architecture-identifier-alignmen
213946 dmarc-architecture-identifier-alignmenwardell henley
 
Cissp chapter-05ppt178
Cissp chapter-05ppt178Cissp chapter-05ppt178
Cissp chapter-05ppt178wardell henley
 
Enterprise%20 security%20architecture%20 %20business%20driven%20security
Enterprise%20 security%20architecture%20 %20business%20driven%20securityEnterprise%20 security%20architecture%20 %20business%20driven%20security
Enterprise%20 security%20architecture%20 %20business%20driven%20securitywardell henley
 
3 securityarchitectureandmodels-120331064706-phpapp01
3 securityarchitectureandmodels-120331064706-phpapp013 securityarchitectureandmodels-120331064706-phpapp01
3 securityarchitectureandmodels-120331064706-phpapp01wardell henley
 
Splunk 7.2.3-security-hardeningstandards
Splunk 7.2.3-security-hardeningstandardsSplunk 7.2.3-security-hardeningstandards
Splunk 7.2.3-security-hardeningstandardswardell henley
 
Ms app 1.5.1-msinfra-bestpracticesguide
Ms app 1.5.1-msinfra-bestpracticesguideMs app 1.5.1-msinfra-bestpracticesguide
Ms app 1.5.1-msinfra-bestpracticesguidewardell henley
 
IBM enterprise Content Management
IBM enterprise Content ManagementIBM enterprise Content Management
IBM enterprise Content Managementwardell henley
 

More from wardell henley (20)

RP_Patch_Management_S508C.pdf
RP_Patch_Management_S508C.pdfRP_Patch_Management_S508C.pdf
RP_Patch_Management_S508C.pdf
 
mita_overview.pdf
mita_overview.pdfmita_overview.pdf
mita_overview.pdf
 
Landscape_Medicaid_Healthcare_Information_Technology.pdf
Landscape_Medicaid_Healthcare_Information_Technology.pdfLandscape_Medicaid_Healthcare_Information_Technology.pdf
Landscape_Medicaid_Healthcare_Information_Technology.pdf
 
Facets Overview and Navigation User Guide.pdf
Facets Overview and Navigation User Guide.pdfFacets Overview and Navigation User Guide.pdf
Facets Overview and Navigation User Guide.pdf
 
self_inspect_handbook_nisp.pdf
self_inspect_handbook_nisp.pdfself_inspect_handbook_nisp.pdf
self_inspect_handbook_nisp.pdf
 
Itil a guide to cab meetings pdf
Itil a guide to cab meetings pdfItil a guide to cab meetings pdf
Itil a guide to cab meetings pdf
 
Mn bfdsprivacy
Mn bfdsprivacyMn bfdsprivacy
Mn bfdsprivacy
 
9 150928065812-lva1-app6892 gmp
9 150928065812-lva1-app6892 gmp9 150928065812-lva1-app6892 gmp
9 150928065812-lva1-app6892 gmp
 
It security cert_508
It security cert_508It security cert_508
It security cert_508
 
15466 mba technology_white_paper
15466 mba technology_white_paper15466 mba technology_white_paper
15466 mba technology_white_paper
 
Best practices for_implementing_security_awareness_training
Best practices for_implementing_security_awareness_trainingBest practices for_implementing_security_awareness_training
Best practices for_implementing_security_awareness_training
 
213946 dmarc-architecture-identifier-alignmen
213946 dmarc-architecture-identifier-alignmen213946 dmarc-architecture-identifier-alignmen
213946 dmarc-architecture-identifier-alignmen
 
Soa security2
Soa security2Soa security2
Soa security2
 
Cissp chapter-05ppt178
Cissp chapter-05ppt178Cissp chapter-05ppt178
Cissp chapter-05ppt178
 
Enterprise%20 security%20architecture%20 %20business%20driven%20security
Enterprise%20 security%20architecture%20 %20business%20driven%20securityEnterprise%20 security%20architecture%20 %20business%20driven%20security
Enterprise%20 security%20architecture%20 %20business%20driven%20security
 
3 securityarchitectureandmodels-120331064706-phpapp01
3 securityarchitectureandmodels-120331064706-phpapp013 securityarchitectureandmodels-120331064706-phpapp01
3 securityarchitectureandmodels-120331064706-phpapp01
 
Splunk 7.2.3-security-hardeningstandards
Splunk 7.2.3-security-hardeningstandardsSplunk 7.2.3-security-hardeningstandards
Splunk 7.2.3-security-hardeningstandards
 
Ms app 1.5.1-msinfra-bestpracticesguide
Ms app 1.5.1-msinfra-bestpracticesguideMs app 1.5.1-msinfra-bestpracticesguide
Ms app 1.5.1-msinfra-bestpracticesguide
 
IBM enterprise Content Management
IBM enterprise Content ManagementIBM enterprise Content Management
IBM enterprise Content Management
 
oracle EBS
oracle EBSoracle EBS
oracle EBS
 

Payment card industry data security standard 1

  • 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