Transcript Information Security Programs

UMASS PCI DSS Compliance Training
Payment Card Industry Data Security Standard (PCI DSS)
Training Program
Version 4
Larry Wilson
October, 2013
1
PCI DSS Training Course
Contents
Module 1
 PCI DSS Introduction
 Payment Industry Terminology
 Payment Transaction Flow
 Service Provider Relationships
Module 2
 Payment Brand Compliance Programs
 SAQ Overview
 PA-DSS Overview
 PCI Roles and Responsibilities
Module 3
 Cardholder Data Discovery
 Network Segmentation
 Scoping the Cardholder Data Environment
4/9/2015
2
Module 1
Module 1 Objectives
After completing this module you will be able to
 Understand the importance of PCI DSS compliance

Describe the role of the Payment Card Industry Security
Standards Council (PCI SSC)
Compliance with PCI DSS
 There are three things to understand about PCI DSS:
- Standards are not optional
 Outline the Payment Card Industry Security Standards
- If you accept payment cards on campus, you are subject to the standards
 Describe the benefits of PCI DSS training
- There are significant financial costs to non-compliance.
 Discuss myths of PCI DSS
 Define Payment Card Industry Terminology
 Define card processing: Authorization, Clearing and Settlement
 Define service provider relationships
 Discuss transaction types: card Not Present and Card Present
 Describe credit card security
 Failure to comply with PCI DSS can result in stiff contractual penalties or
sanctions from members of the payment card industry including:
- Fines of $500,000 per data security incident
- Fines of $50,000 per day for non-compliance with published standards
- Liability for all fraud losses incurred from compromised account numbers
- Liability for the cost of re-issuing cards associated with the compromise
- Suspension of merchant accounts
 Non compliance is not worth the risk.
 It only takes one incident of data compromise to put the university at risk
4/9/2015
3
Module 1
PCI DSS Introduction
What is PCI SSC?
PCI Standards
 PCI Security Standards Council (PCI SSC) was created in 2006 as
an independent standards body to provide oversight f the
development and management of payment Card Industry
Security Standards on a global basis
 PCI DSS covers security of the environments that store, process or transmit
account data
 Created to align security programs of MasterCard and Visa
- Later was adopted by other major card programs
 PCI PA-DSS covers secure payment applications to support PCI DSS
compliance
- Founding members of the council included American Express,
Discover, JCB, MasterCard Worldwide, and Visa International.
 PCI PTS covers tamper detection, cryptographic processes, and other
mechanisms used to protect the PIN
Resources Provided by the Council
 PCI DSS, PCI PTS, PCI PA-DSS, P2PE, PIN Security and supporting
documents
 Roster of QSAs (Qualified Security Assessors), ASVs (Approved
Scanning Vendors), validated payment applications, PTS Devices,
and P2PE solutions
 PCI PTS covers tamper detection, cryptographic processes, and other
mechanisms used to protect the PIN
 PCI P2PE covers encryption, decryption and key management within secure
cryptographic devices
 PCI PIN Security covers secure management, processing and transmission of
personal identification number (PIN) data during online and offline payment
card transaction processing
 PCI Security Standards Council FAQs
 Education and Outreach Programs
 Participating Organization Membership, Meetings, Feedback
4/9/2015
4
Module 1
PCI DSS Introduction
Who does PCI DSS apply to?
 UMASS Merchants must be PCI DSS compliant and are responsible for
ensuring their compliance:
- The program applies to all payment channels, including: in person
(Point of Sale), mail / telephone order and/or e-commerce.
- The training is applicable to all campus personnel who have access to
credit card information, as a processor of credit card transactions or
as a reviewer of reports that contain credit card data
How does it work?
 University Merchants and Service Providers must adhere to PCI DSS
- A single approach to safeguard sensitive data for all card brands
- Compliance validation ensures appropriate levels of cardholder data
security are maintained
Why is this important?
 This training provides knowledge and skills necessary to ensure credit
card security at the university
 Everyone, not just the credit card companies, benefits from the effective
application of credit card security measures
4/9/2015
Benefits of PCI DSS Training
Our Customers
 Appreciate your ability to reduce the threat of identity theft
 Trust you to complete transactions without duplicate or invalid
charges
 Enjoy peace of mind, knowing that their credit card information is
in good hands
The University
 Takes pride in a skilled workforce
 Values your ability to build customer confidence
 Needs your help in limiting potential losses, fines and penalties
… and You
 Have confidence in your ability to safely and efficiently do your job
 Are alert to the warning signs of fraud
 Know you can make informed decisions under pressure
5
Module 1
Myths of PCI DSS
Myth 1 – One vendor and product will make us compliant
 No single vendor or product fully addresses all 12 requirements of
PCI DSS.
Myth 2 – Outsourcing card processing makes us compliant
 Outsourcing simplifies but does not provide automatic compliance
 We must ensure providers comply with PCI standards
 Request a certificate of compliance annually from providers.
Myth 3 – PCI compliance is an IT project
 The IT staff implements technical and operational aspects
 PCI compliance is an ongoing process of assessment, remediation,
reporting
Myth 4 – PCI will make us secure
 Successful completion of a scan or assessment is a snapshot in time
 Security exploits are non-stop and get stronger every day
 PCI compliance efforts are a continuous process of assessment and
remediation to ensure safety of cardholder data.
Myth 5 – PCI is unreasonable; it requires too much
 Most aspects of PCI DSS are a common best practice for security
Myth 6 – PCI requires us to hire a Qualified Security Assessor
 PCI DSS provides the option of doing an internal assessment with
an officer sign-off if acquirer and/or merchant bank agree
Note: The Commonwealth of Massachusetts Controllers office
requires the University to hire a QSA to conduct an independent
assessment on an annual basis.
Myth 7 – We don’t take enough credit cards to be compliant
 PCI compliance is required for any business that accepts payment
cards – even if the quantity of transactions is just one
Myth 8 – We completed a SAQ so we’re compliant
 Technically, this is true for merchants who are not required to do
on-site assessments for PCI DSS compliance. True security of
cardholder data requires non-stop assessment and remediation
to ensure that likelihood of a breach is kept as low as possible.
Myth 9 – PCI makes us store cardholder data
 Both PCI DSS and the payment card brands strongly discourage
storage of cardholder data by merchants and processors
Myth 10 – PCI is too hard
 Understanding PCI DSS can seem daunting, especially for
merchants without security or a large IT department.
 However, PCI DSS mostly calls for good, basic security
4/9/2015
6
Module 1
Payment Industry Terminology
Cardholder
 Customer purchasing goods as either a “Card Present” or card Not
Present” transaction
 Receives the payment card and bills from the issuer
Issuer
 Bank or other organization issuing a payment card on behalf of a
Payment Brand (e.g. MasterCard & Visa)
 Payment Brand issuing a payment card directly (e.g. Amex,
Discover, JCB)
Merchant
 Organization accepting the payment card for payment during a
purchase
Acquirer
 Bank or entity the merchant uses to process their payment card
transactions
 Receive authorization request from merchant and forward to Issuer
for approval
 Provide authorization, clearing and settlement services to
merchant
Payment Brand Compliance Programs
 Tracking and enforcement
 Penalties, fees, compliance deadlines
 Validation process and who needs to validate
 Approval and posting of compliant entities
 Definition of merchants and service provider levels
 Forensics and response to account data compromises
Common Acquirer Responsibilities
 Acquirer is responsible for merchant compliance
- Ensure that their merchants understand PCI DSS compliance
requirements and track compliance efforts
- Manage merchant communications
 Work with merchants until full compliance has been validated
- Merchants are not compliant until all requirements have been met
and validated
- Acquirer is responsible for providing merchant compliance status to
payment brands
 Incur any liability that may result from non-compliance with payment
brand compliance programs
Payment Brand
 Include American Express, Discover, JCB, MasterCard Worldwide,
and Visa International
 Each payment brand develops and maintains its own PCI DSS
compliance program in accordance with its own security risk
management policies
4/9/2015
7
Module 1
Credit Card Processing
Authorization (time of purchase)
 Every request receives a response that directs the
acquirer or the merchant on how to proceed with
the transaction (Approve or Deny)
Clearing (within one day)
 Involves daily processing and routing of financial
transactions between card brands, acquirers and
issuers
Settlement (within two days)
 Involves funds transfer for the purpose of the
financial settlement of clearing transactions, fees,
and other transfer of funds between card brands,
acquirers and issuers.
4/9/2015
8
Module 1
How Payment Processing Works (Technical Process)
4/9/2015
9
Module 1
Service Providers
Service Providers
A service provider is a business entity directly involved with the processing,
storage, transmission, or switching of transaction data and cardholder data.
Payment Gateways
This diagram illustrates how real-time, electronic credit card processing
works using CyberSource Payment Services.
Service providers include companies that provide services which control or
could impact the security of cardholder data.
Service provider examples:
 Transaction processors
 Payment Gateways
 Independent sales Organizations (ISOs)
 External Sales Organizations (ESOs)
 Customer Service functions
 Remittance processing companies
 Managed firewall and Intrusion Detection Service (I DS) service providers
 Web Hosting and Data Center Hosting providers
4/9/2015
1. Purchaser places order
2. Merchant securely transfers order information to CyberSource over
the Internet. CyberSource receives order information and performs
requested services
3. CyberSource formats the transaction detail appropriately and
securely routes the transaction authorization request through its
payment gateway to the processor.
4. The transaction is then routed to the issuing bank (purchaser's
bank) to request transaction authorization
5. The transaction is authorized or declined by the issuing bank or card
(Discover, American Express).
6. CyberSource returns the message to the merchant.
7. Issuing bank approves transfer of money to acquiring bank
8. The acquiring bank credits the merchant's account
10
Module 1
Transaction Types & Card Security
Credit Card Security
Merchant Configurations
Card Not Present Transactions
Card Not Present Transaction - the credit card information is keyed into a credit
card processing system (credit card terminal, software program, or payment
gateway) without the credit card or customer present at the time of the sale.
Card Present Transactions
Wireless
Terminal
Tap & Go
Wireless
Terminal
Imprint
Machine
Internet
Connected
Terminal
Dial-up
Terminal
Card Present Transaction (Point of Sale) - the customer and credit card are
present at the point of sale. The card is swiped through a credit card processing
system (credit card terminal, POS system or card reader) that obtains the card
holder's information by reading the magnetic stripe on the back of the card.
4/9/2015
11
Module 2
Module 2 Objectives
After completing this module you will be able to
PCI DSS Standards Framework
 Understand the PCI DSS Standards Framework
 Understand Merchant Compliance Requirements
PCI DSS Requirements – Validated by Self or Outside Assessment
 Describe the Self Assessment Questionnaire (SAQ)
Build and maintain a secure network
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
 Understand SAQ Instructions and Guidelines
 Describe the three step PCI DSS Compliance Approach
 Understand Merchant and Service Provider Compliance Levels
 Understand Merchant and Service Provider Compliance
Validation
 Understand Payment Application data Security Standard (PA-DSS)
 Understand PCI Roles and Responsibilities
Protect cardholder data
3. Protect sensitive data
4. Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management program
5 Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
Implement strong access control measures
7 Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
Regularly monitor and test networks
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an Information Security Policy
12. Maintain a policy that addresses Information security
4/9/2015
12
Module 2
PCI DSS Standards Requirements
Requirement 1: Install and maintain a firewall configuration
to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system
passwords and other security parameters
 Firewalls are devices that control computer traffic allowed
between an entity’s networks (internal) and untrusted networks
(external), as well as traffic into and out of more sensitive areas
within an entity’s internal trusted networks. The cardholder data
environment is an example of a more sensitive area within an
entity’s trusted network.
 Malicious individuals (external and internal to an entity) often use vendor
default passwords and other vendor default settings to compromise
systems. These passwords and settings are well known by hacker
communities and are easily determined via public information.
 A firewall examines all network traffic and blocks those
transmissions that do not meet the specified security criteria.
 Protection methods such as encryption, truncation, masking, and hashing
are critical components of cardholder data protection. If an intruder
circumvents other security controls and gains access to encrypted data,
without the proper cryptographic keys, the data is unreadable and
unusable to that person. Other effective methods of protecting stored data
should be considered as potential risk mitigation opportunities. For
example, methods for minimizing risk include not storing cardholder data
unless absolutely necessary, truncating cardholder data if full PAN is not
needed, and not sending unprotected PANs using end-user messaging
technologies, such as e-mail and instant messaging.
 All systems must be protected from unauthorized access from
untrusted networks, whether entering the system via the Internet
as e-commerce, employee Internet access through desktop
browsers, employee e-mail access, dedicated connections such as
business-to-business connections, via wireless networks, or via
other sources. Often, seemingly insignificant paths to and from
untrusted networks can provide unprotected pathways into key
systems. Firewalls are a key protection mechanism for any
computer network.
 Other system components may provide firewall functionality,
provided they meet the minimum requirements for firewalls as
provided in Requirement 1. Where other system components are
used within the cardholder data environment to provide firewall
functionality, these devices must be included within the scope
and assessment of Requirement 1.
4/9/2015
Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open,
public networks
 Sensitive information must be encrypted during transmission over
networks that are easily accessed by malicious individuals. Misconfigured
wireless networks and vulnerabilities in legacy encryption and
authentication protocols continue to be targets of malicious individuals
who exploit these vulnerabilities to gain privileged access to cardholder
data environments.
13
Module 2
PCI DSS Standards Requirements
Requirement 5: Use and regularly update anti-virus software or
programs
Requirement 8: Assign a unique ID to each person with computer
access
 Malicious software, commonly referred to as ―malware‖—including
viruses, worms, and Trojans—enters the network during many
business-approved activities including employee e-mail and use of
the Internet, mobile computers, and storage devices, resulting in the
exploitation of system vulnerabilities. Anti-virus software must be
used on all systems commonly affected by malware to protect
systems from current and evolving malicious software threats.
 Assigning a unique identification (ID) to each person with access ensures
that each individual is uniquely accountable for his or her actions. When
such accountability is in place, actions taken on critical data and systems
are performed by, and can be traced to, known and authorized users.
Requirement 6: Develop and maintain secure systems and
applications
 Unscrupulous individuals use security vulnerabilities to gain
privileged access to systems. Many of these vulnerabilities are fixed
by vendor-provided security patches, which must be installed by the
entities that manage the systems. All critical systems must have the
most recently released, appropriate software patches to protect
against exploitation and compromise of cardholder data by
malicious individuals and malicious software.
Requirement 7: Restrict access to cardholder data by business
need to know
 To ensure critical data can only be accessed by authorized
personnel, systems and processes must be in place to limit access
based on need to know and according to job responsibilities.
4/9/2015
Requirement 9: Restrict physical access to cardholder data
 Any physical access to data or systems that house cardholder data provides
the opportunity for individuals to access devices or data and to remove
systems or hardcopies, and should be appropriately restricted. For the
purposes of Requirement 9, ―onsite personnel‖ refers to full-time and
part-time employees, temporary employees, contractors and consultants
who are physically present on the entity’s premises. A ―visitor‖ refers to a
vendor, guest of any onsite personnel, service workers, or anyone who
needs to enter the facility for a short duration, usually not more than one
day. ―Media‖ refers to all paper and electronic media containing
cardholder data.
Requirement 10: Track and monitor all access to network resources
and cardholder data
 Logging mechanisms and the ability to track user activities are critical in
preventing, detecting, or minimizing the impact of a data compromise. The
presence of logs in all environments allows thorough tracking, alerting, and
analysis when something does go wrong. Determining the cause of a
compromise is very difficult, if not impossible, without system activity logs.
14
Module 2
PCI DSS Standards Requirements
Requirement 11: Regularly test security systems and processes.
 Vulnerabilities are being discovered continually by malicious
individuals and researchers, and being introduced by new software.
System components, processes, and custom software should be
tested frequently to ensure security controls continue to reflect a
changing environment.
Requirement 12: Maintain a policy that addresses information
security for all personnel.
 A strong security policy sets the security tone for the whole entity
and informs personnel what is expected of them. All personnel
should be aware of the sensitivity of data and their responsibilities
for protecting it. For the purposes of Requirement 12, ―personnel‖
refers to full-time and part-time employees, temporary employees,
contractors and consultants who are ―resident‖ on the entity’s site
or otherwise have access to the cardholder data environment.
Compliance with PCI DSS
 Required by all entities that store, process, transmit cardholder
information
 PCI Compliant requires an entity to comply with all PCI DSS requirements
 PCI DSS compliance is dependent on:
- Merchant or service provider level
- Payment brand compliance validation and reporting requirements
- University requirements for compliance
 Non compliance can result in fines levied by credit card companies against
merchants, processors and acquiring banks
Merchant Compliance Requirements







Understand the PCI DSS standards and compliance requirements
Sufficient technical knowledge in the security domains covered by PCI DSS
Understand credit card business processes and data flows
Identify systems and processes subject to PCI DSS assessments
Comply with requirements of the PCI DSS standards
Understand and comply with University e-commerce standards
Complete PCI DSS self-assessment and remediate gaps found
Acquiring Bank’s Compliance Requirements (Vantiv)
 Meet requirements of individual credit card brand including reporting on
service provider and merchant
Processor Compliance Requirements (CyberSource, NelNet)
 Payment processors should provide annual proof of PCI compliance
4/9/2015
15
Module 2
PCI DSS Standards Framework
The Self-Assessment Questionnaire (SAQ)
The “SAQ” is a self-validation tool for merchants and service providers who
are not required to do on-site assessments for PCI DSS compliance.
The SAQ includes a series of yes-or-no questions for compliance.
If an answer is no, the university must state the future remediation date and
associated actions.
SAQ A
Card Not Present – All Cardholder Data Functions Outsourced
SAQ A has been developed to address requirements applicable to merchants who
retain only paper reports or receipts with cardholder data, do not store
cardholder data in electronic format and do not process or transmit any
cardholder data on their systems or premises.
A
Card not present (e-commerce or mail / telephone order)
merchants, all cardholder data functions outsources. This would
never apply to face to face merchants.
B
Imprint-only merchants with no electronic cardholder data storage,
or standalone, dial out terminal merchants with no electronic
cardholder data storage
SAQ A merchants do not store cardholder data in electronic format, do not
process or transmit any cardholder data on their systems or premises, and
validate compliance by completing SAQ A and the associated Attestation of
Compliance, confirming that:
 Your company accepts only card-not-present (e-commerce or
mail/telephone-order) transactions;
 Your company does not store, process, or transmit any cardholder data on
your systems or premises, but relies entirely on a third party(s) to handle all
these functions;
 Your company has confirmed that the third party(s) handling storage,
processing, and/or transmission of cardholder data is PCI DSS compliant;
 Your company retains only paper reports or receipts with cardholder data,
and these documents are not received electronically; and
 Your company does not store any cardholder data in electronic format.
C-VT
Merchants using only web-based virtual terminals, no electronic
cardholder data storage
SAQ A includes 13 questions.
SAQ
Description
C
Merchants with payment application systems connected to the
Internet, no electronic cardholder data storage
D
All other merchants not included in descriptions for SAQ A through C
above, and all service providers defined by a payment brand as
eligible to complete an SAQ.
4/9/2015
16
Module 2
Self-Assessment Questionnaire (SAQ)
SAQ B
Merchants with Only Imprint Machines or Only Standalone,
Dial-Out Terminals. No Electronic Cardholder Data Storage.
SAQ C-VT
Merchants with Web-Based Virtual Terminals, No Electronic
Cardholder Data Storage
SAQ B has been developed to address requirements applicable to merchants who
process cardholder data only via imprint machines or standalone, dial-out
terminals.
SAQ C-VT has been developed to address requirements applicable to merchants who process
cardholder data only via isolated virtual terminals on personal computers connected to the
Internet.
SAQ B merchants only process cardholder data via imprint machines or via
standalone, dial-out terminals, and may be either brick-and-mortar (cardpresent) or e-commerce or mail/telephone order (card-not-present) merchants.
Such merchants validate compliance by completing SAQ B and the associated
Attestation of Compliance, confirming that:
 Your company uses only an imprint machine and/or uses only standalone,
dial-out terminals (connected via a phone line to your processor) to take
your customers’ payment card information;
 The standalone, dial-out terminals are not connected to any other systems
within your environment;
 The standalone, dial-out terminals are not connected to the Internet;
 Your company does not transmit cardholder data over a network (either an
internal network or the Internet);
 Your company retains only paper reports or paper copies of receipts with
cardholder data, and these documents are not received electronically; and
 Your company does not store cardholder data in electronic format.
SAQ B includes 29 questions.
This SAQ option is intended to apply only to merchants who manually enter a single
transaction at a time via a keyboard into an Internet-based virtual terminal solution. SAQ CVT merchants process cardholder data via virtual terminals on personal computers
connected to the Internet, do not store cardholder data on any computer system, and may
be brick-and-mortar (card-present) or mail/telephone-order (card-not-present) merchants.
Such merchants validate compliance by completing SAQ C-VT and the associated Attestation
of Compliance, confirming that:
 Your company’s only payment processing is done via a virtual terminal accessed by an
Internet connected web browser;
 Your company’s virtual terminal solution is provided and hosted by a PCI DSS validated
third party service provider;
 Your company accesses the PCI DSS compliant virtual terminal solution via a computer
that is isolated in a single location, and is not connected to other locations or systems
within your environment (this can be achieved via a firewall or network segmentation to
isolate the computer from other systems);
 Your company’s computer does not have software installed that causes cardholder data
to be stored (for example, there is no software for batch processing or store-andforward);
 Your company’s computer does not have any attached hardware devices that are used
to capture or store cardholder data (for example, there are no card readers attached);
 Your company does not otherwise receive or transmit cardholder data electronically
through any channels (for example, via an internal network or the Internet);
 Your company retains only paper reports or paper copies of receipts; and
 Your company does not store cardholder data in electronic format.
SAQ C-VT includes 51 questions.
4/9/2015
17
Module 2
Self-Assessment Questionnaire (SAQ)
SAQ C
Merchants with Payment Application Systems Connected to the
Internet, No Electronic Cardholder Data Storage
SAQ D
All Other Merchants and All Service Providers Defined by a
Payment Brand as Eligible to Complete an SAQ
SAQ C has been developed to address requirements applicable to merchants
whose payment application systems (for example, point-of-sale systems) are
connected to the Internet (for example, via DSL, cable modem, etc.) either
because:
1. The payment application system is on a personal computer that is connected
to the Internet (for example, for e-mail or web browsing), or
2. The payment application system is connected to the Internet to transmit
cardholder data.
SAQ D has been developed for all service providers defined by a payment brand
as eligible to complete an SAQ, as well as SAQ-eligible merchants who do not
meet the descriptions of SAQ types A through C, above.
SAQ C merchants process cardholder data via POS machines or other payment
application systems connected to the Internet, do not store cardholder data on
any computer system, and may be either brick-and-mortar (card-present) or ecommerce or mail/telephone-order (card-not-present) merchants.
SAQ C merchants validate compliance by completing SAQ C and the associated
Attestation of Compliance, confirming that:
 Your company has a payment application system and an Internet connection
on the same device and/or same local area network (LAN);
 The payment application system/Internet device is not connected to any
other systems within your environment (this can be achieved via network
segmentation to isolate payment application system/Internet device from all
other systems);
 Your company store is not connected to other store locations, and any LAN is
for a single store only;
 Your company retains only paper reports or paper copies of receipts;
 Your company does not store cardholder data in electronic format; and
 Your company’s payment application software vendor uses secure
techniques to provide remote support to your payment application system.
SAQ D service providers and merchants validate compliance by completing
SAQ D and the associated Attestation of Compliance.
While many of the organizations completing SAQ D will need to validate
compliance with every PCI DSS requirement, some organizations with very
specific business models may find that some requirements do not apply.
For example, a company that does not use wireless technology in any capacity
would not be expected to validate compliance with the sections of the PCI DSS
that are specific to managing wireless technology.
SAQ D includes 288 questions.
SAQ C includes 40 questions.
4/9/2015
18
Module 2
SAQ Instructions and Guidelines





SAQ Instructions & Guidelines
Which SAQ do I complete?
SAQ A
Outsource all CHD
SAQ B
Imprint or standalone dialout terminals only
SAQ C-VT
Virtual Terminals Only
SAQ C
Internet-connected
Payment application
SAQ D
All other merchants and
service providers
Card-not-present, all
cardholder data (CHD)
functions outsourced
Imprint or standalone, dialout terminals only, no
electronic CHD storage
Web-based virtual terminals
only, no electronic CHD
storage
POS or payment system
connected to Internet, no
electronic CHD storage
All other merchants and all
service providers eligible to
complete an SAQ
Card not-present only
No CHD on any systems
or premises, all
outsourced
Third parties are PCI
DSS compliant
Only paper is retained
No electronic storage of
CHD






Imprint machine or
standalone dial-out
terminals only
Dial-out terminals not
connected to any other
systems
Dial-out terminals not
connected to the
Internet, connected via
phone line to your
processor or acquirer
No CHD over Internet
Only paper is retained
No electronic storage of
CHD








No
Is this my
merchant
type?
Yes
SAQ A
(13 questions) and
Attestation
4/9/2015
No
Is this my
merchant
type?
Yes
SAQ B
(29 questions) and
Attestation
Third-party hosted virtual terminal
only, accessed by an Internetconnected web browser
Merchant computer not connected
to any other systems within
environment
Isolated in a single location, not
connected to other locations or
systems within environment (can
be achieved with network
segmentation)
Virtual terminal solution provided
and hosted by PCI DSS validated
service provider
No software installed or hardware
attached to merchant computer
that captures CHD
No other electronic transmission
of CHD
Only paper is retained
No electronic storage of CHD
No
Is this my
merchant
type?
Yes
SAQ C-VT
(51 questions) and
Attestation






POS or payment system
and Internet on same
device and/or same Local
Area Network (LAN)
Payment application
system / hardware device
not connected to any
other systems
Single store location
Only paper is retained
No electronic storage of
CHD
POS vendor provides
secure support
No
Is this my
merchant
type?
Yes
SAQ C
(40 questions) and
Attestation
Yes
SAQ D
(288 questions) and
Attestation
19
Module 2
PCI DSS Compliance Approach
Step 1 – Assess
Step 2 – Remediate
Goal: Identify technology and process vulnerabilities
posing a security risk of cardholder data transmitted,
processed or stored by the university.
Goal: Remediation is the process of fixing
vulnerabilities – including technical flaws in
software code or unsafe practices in how the
university processes or stores cardholder data.
Step 1.1 - Study PCI DSS Standard - Learn what the
standard requires of the business
Step 2.1 - Scan your network with software tools
that analyze infrastructure and spot known
vulnerabilities
Step 1.2 - Inventory IT Assets and Processes
 Identify systems, personnel, processes involved in
transmission, processing, storing cardholder data.
 Determine how cardholder data flows from
beginning to end of the transaction process.
 Check versions of personal identification number
(PIN) entry terminals and software to ensure they
are PCI compliant.
Step 1.3 - Find Vulnerabilities - Use the appropriate
SAQ to guide the assessment, and technologies to locate
insecure systems
Step 1.4 - Validate with Third-Party Experts - May
require a Qualified Security Assessor (QSA) and/or
Approved Scanning Vendor (ASV) to execute proper
assessment.
Note: Liability for PCI compliance extends to third
parties involved with the process flow, so we must
confirm that they are compliant.
4/9/2015
Step 3 – Report
 Regular reports are required for PCI compliance;
these are submitted to the acquiring bank and
card payment brands that you do business with.
 PCI SSC is not responsible for PCI compliance.
Step 2.2 - Review and remediate vulnerabilities
found during on-site assessment (if applicable) or
through the Self-Assessment Questionnaire (SAQ)
process
 All qualifying merchants and processors must
submit a quarterly scan report, which must be
completed by a PCI approved ASV.

Businesses must submit an annual Attestation
within the Self-Assessment Questionnaire (SAQ).
Step 2.3 - Classify and rank the vulnerabilities to
help prioritize the order of remediation, from
most serious to least serious
Step 2.4 - Apply patches, fixes, and changes to
unsafe processes and workflow
Step 2.5 - Re-scan to verify that remediation
actually occurred
Note: Remediation should occur as soon as
practical when a vulnerability is discovered via the
Assessment process (Step 1).
20
Module 2
Merchant Levels and Compliance Validation
Level
Merchant Criteria
Validation Requirements

1
Merchants processing over 6
million Visa transactions
annually

Annual Report on Compliance (ROC) by
a Qualified Security Assessor (QSA) or
internal auditor if signed by officer of
the company
Service Provider Levels and Compliance Validation
Level
Validation Action

Annual On-site PCI Data
Security Assessment

Quarterly Network Scan

Annual PCI Self-Assessment
Questionnaire

Quarterly Network Scan
1
Quarterly network scan by Approved
Scanning Vendor (ASV)
2
2
3
4
Merchants processing 1
million to 6 million Visa
transactions annually
Merchants processing
20,000 to 1 million visa ecommerce transactions
annually
Merchants processing less
than 20,000 Visa ecommerce transactions
annually

Attestation of Compliance Form

Annual Self-Assessment Questionnaire
(SAQ)

Quarterly network scan by ASV

Attestation of Compliance Form

Annual SAQ

Quarterly network scan by ASV if
applicable

Attestation of Compliance Form

Annual SAQ recommended

Quarterly network scan by ASV if
applicable

Compliance validation requirements
set by acquirer
Validated By

Qualified Security Assessor (QSA)

Approved Scanning Vendor (ASV)

Service Provider

Approved Scanning Vendor (ASV)
Level 1:
 All Third Party Processors (TPPs) and Data Storage Entities (DSEs) that store,
transmit or process less than 1,000,000 combined MasterCard and Maestro
transactions annually.
 Additionally, All compromised TPPs and DSE’s
Level 2:
 All DSEs that store, transmit or process less than 1,000,000 combined
MasterCard and Maestro transactions annually
Note: UMASS is designated as a Level 3 Merchant but we report as a Level 2 Merchant
4/9/2015
21
Module 2
Payment Application Data Security Standard (PA-DSS)
PA -DSS Overview
Assessing Environments with PA-DSS Applications
 PA-DSS is a comprehensive set of requirements designed for payment
application software vendors to facilitate their customer’s PCI DSS
compliance.
 Use of PA-DSS compliant application by itself does not make an entity
PCI-DSS compliant
 Distinct but aligned with OPCI-DSS
 PA-DSS applies to third party applications that perform authorization
and/or settlement.
 PA-DSS does not apply to payment applications that are typically sold
and installed “off the shelf” without much customization by software
vendors.
 PA-DSS does not apply to payment applications provided in modules,
which typically includes a “baseline” module and other modules specific
to customer types or functions, or customized per customer request.
 PA-DSS validated payment applications are included in the scope of a
PCI-DSS assessment
 The assessor should not challenge the PA-DSS validation
 PCI-DSS assessment of validated payment applications should verify the
payment application is implemented into a PCI-DSS compliant
environment and the payment application is implemented according to
the PA-DSS Implementation Guide
 All other system components in scope for PCI DSS must still be assessed
 The assessor should focus their assessment on the application’s
implementation in accordance with the vendor’s implementation guide.
 PA-DSS does not apply to a payment application developed and sold to
only one customer since this application will be covered a part of the
customer’s PCI DSS compliance review.
 PCI-DSS does not apply to payment applications developed by
merchants and service providers if used only in-house (not sold to a
third party).
 PA-DSS does not apply to operating systems onto which a payment
application is installed, database systems that store cardholder data or
back-office systems that source cardholder data.
4/9/2015
22
Module 2
Roles & Responsibilities
PCI Security Standards Council
Merchant & Service Providers
 Maintain PCI-DSS, PA-DSS, PTS, P2PE, and PIN Security standards and
supporting documentation
 Define, implement validation requirements for QSAs, PA-QSAs, ASVs, ISAs
 Approve companies and their employees to perform PCI –DSS
Assessments, Payment Application Assessments, ASV Scanning
 Maintain list of validated payment applications, P2PE solutions, PIN
transaction security devices, QSA, PA-QSA, ASV companies
 Offer training for the QSAs, PA-QSAs, ASVs, and ISAs
 Promote PCI security on a global basis
 Review and understand the PCI Security Standards
 Understand the compliance validation and reporting requirements
defined by the payment card brands
 Validate and report compliance to acquirer or payment card brand
 Maintain ongoing compliance, not just during assessment
 Read and incorporate communications from the payment brands,
acquirers, and the PCI SSC
Internal Security Assessors
Development and enforcement of compliance programs
Fines or penalties for non-compliance
Endorse QSA, PA-QSA and ASV company qualification criteria
Accept validation documentation from approved QSA, PA-QSA, and ASV
companies and their employees
 Provide feedback to council on QSA, PA-QSA and ASV performance
 Forensic investigation and account data compromise
 Validate the scope of the assessment
 Verify all technical information given by stakeholders using
independent judgment to confirm requirements have been met
 Provide support and guidance during the compliance process
 Be on-site for the duration of any relevant assessment procedure
 Review the work that supports the assessment procedures
 Ensure adherence to PCI-DSS Requirements
 Select business facilities and system components for sampling
 Evaluate compensating controls and produce final report
Qualified Security Assessor (QSA)
Approved Scanning Vendor (ASV)
 Validate the scope of the assessment
 Conduct PCI-DSS assessments
 Verify all technical information given by merchant or service provider
using independent judgment to confirm requirements are met
 Be on-site for the duration of any relevant assessment procedure
 Review the work that supports the assessment procedures
 Ensure adherence to PCI-DSS Requirements and Assessment Procedures
 Select business facilities and system components where sampling is used
 Evaluate compensating controls and produce Report on Compliance (ROC)
 Perform external vulnerability scans via PCI-DSS Requirement 11.2
 Make reasonable efforts to ensure scans do not impact normal
operation of the customer environment and do not penetrate or
intentionally alter the customer environment
 Scan all IP ranges and domains provided by the customer to identify
active IP addresses and services
 Provide a determination as to whether the scan customer’s
components have passed scanning requirements
 Provide adequate documentation to demonstrate the compliance or
non-compliance of the scan customer’s components.
Payment Card Brands




4/9/2015
23
Module 3
UMASS e-Commerce Committee & Security Council
Roles and Responsibilities
UMASS Campus / President’s Office e-Commerce and Information Security Representative
Roles and Responsibilities – Merchant Compliance (Campus and President’s Office)
 Manage campus merchant’s inventory spreadsheet and compliance WorkShare site
 Manage campus merchant’s annual Self Assessments Questionnaires (SAQs)
 Manage campus merchant’s QSA Security Assessments (new implementations)
 Manage campus merchant’s Quarterly Scans (if applicable)
 Manage campus merchant’s annual PCI DSS training
 Manage campus merchant’s ongoing communications and updates (as needed)
UMASS President’s Office e-Commerce and Information Security Representative
Roles and Responsibilities – QSA Contracts and Statement of Work (SOW)
 Manage QSA (Lighthouse, DRG) Statement of Work
 Manage QSA and ongoing communications and updates (as needed)
UMASS President’s Office e-Commerce and Information Security Representative
Roles and Responsibilities – Service providers
 Manage service provider (CyberSource, NelNet) compliance (see note) responsibility
 Manage service provider ongoing communications and updates (as needed)
Note: Treasurer’s Office is responsible for CyberSource and NelNet. The Campus and the departments are responsible for other service provider’s being
used.
UMASS President’s Office e-Commerce and Information Security Representative
Roles and Responsibilities – Acquiring Bank
 Manage acquiring bank (Fifth Third Bank) compliance
 Manage acquiring bank ongoing communications and updates (as needed)
4/9/2015
24
Module 3
UMASS Merchant and Service Provider Compliance Checklist
Merchant’s Compliance Checklist:
Service Provider’s Compliance Checklist:
New install requirements
1. All new Merchant Installs must include a documented PCI Security Assessment
completed by a Qualified Security Assessor (QSA) – either Lighthouse or DRG.
Annual re-certification requirements
This requirements is for new on-line installations that are using software in lieu of or
in addition to CyberSource or Commerce Manager (non-traditional configurations)
All Service Providers must complete and sign the necessary contracts to attest
that they are authorized Third Party Service Providers for the University of
Massachusetts before services are engaged. Annually, they must provide
evidence of their PCI compliance to the University of Massachusetts.
Annual re-certification requirements
1. The campus representatives are responsible for maintaining the Merchant
inventory (with the cooperation of the Merchants)
2. All Merchants must attest by completing the appropriate SAQ, with University of
Massachusetts Treasurer’s Office - Treasurer’s Fiscal Procedure No. 08-01
including all requirements of Section A: Operational, Section B: Inventory,
Section C: PCI Compliance, and Section D: Online Third Party Requirements.
3. All Merchants must attest and provide evidence of compliance with PCI SelfAssessment Questionnaire (SAQ) Type A, B, C-VT, C, or D as appropriate. The
Treasurer’s office will distribute a university developed questionnaire to be
completed and returned by the merchants.
4. All Merchants (as required) must complete and provide Quarterly Vulnerability
Scan results.
5. All Merchants must complete and provide evidence of completion the University
of Massachusetts PCI training (see note).
Note: This is a new requirement starting April, 2012.
4/9/2015
25
Appendix
UMASS Self Assessment Questionnaire – Type A (SAQ A)
Card Not Present – All Cardholder Data Functions Outsourced
SAQ A Merchants Requirements
Such merchants validate compliance by completing SAQ A and the
associated Attestation of Compliance, confirming that:
 Handles only card-not-present (e-commerce or mail/telephone-order)
transactions;
 Does not store, process, or transmit any cardholder data on your
systems or premises, but relies entirely on third party service provider(s)
to handle all these functions;
 Has confirmed that the third party(s) handling storage, processing,
and/or transmission of cardholder data is PCI DSS compliant;
 Retains only paper reports or receipts with cardholder data, and these
documents are not received electronically; and
 Does not store any cardholder data in electronic format.
Treasurer’s Fiscal Procedure No. 08-01
 Section A – A.1, A.2, A.5, A.6, A.8
 Section B – B.1, B.2, B.3
 Section C – C.1, C.6, C.7, C.8, C.9
 Section D – D.1, D.2, D.3, D.4, D.5
4/9/2015
26
Appendix
UMASS Self Assessment Questionnaire – Type B (SAQ B)
Merchants with Only Imprint Machines or Only Standalone, Dial-Out Terminals. No Electronic Cardholder Data Storage.
SAQ B Merchants Requirements
Such merchants validate compliance by completing SAQ B and the
associated Attestation of Compliance, confirming that:
 Use only imprint machines and/or uses only standalone, dial-out
terminals (connected via a phone line to your processor) to take your
customers’ payment card information;
 The standalone, dial-out terminals are not connected to any other
systems within your environment;
 The standalone, dial-out terminals are not connected to the Internet;
 Do not transmit cardholder data over a network (either an internal
network or the Internet);
 Retains only paper reports or paper copies of receipts with cardholder
data, and these documents are not received electronically; and
 Does not store cardholder data in electronic format.
Treasurer’s Fiscal Procedure No. 08-01
 Section A – A.1, A.2, A.5, A.6, A.8
 Section B – B.1, B.2, B.3
 Section C – C.1, C.6, C.7, C.8, C.9
 Section D – D.1, D.2, D.3, D.4, D.5
4/9/2015
27
Appendix
UMASS Self Assessment Questionnaire – Type B (SAQ B)
Merchants with Only Imprint Machines or Only Standalone, Dial-Out Terminals. No Electronic Cardholder Data Storage.
4/9/2015
28
Appendix
UNIVERSITY OF MASSACHUSETTS TREASURER’S OFFICE
Treasurer’s Fiscal Procedure No. 08-01
Effective Date: March 1, 2012
Fiscal Standard and Procedure – E-Commerce and PCI
Section A: Operational
Overall
1. Campus merchants (departments) may not store in any manner full 16 digit credit card
numbers (PAN).
2. Unprotected PAN (Primary Account Number) should not be sent via end-user messaging
technologies including but not limited to email, instant messaging, text message, or
social media.
3. All requests for credit card receipt copies and chargebacks must be processed
immediately. Failure to respond before the deadline will result in the chargeback being
processed by the card company. Credit card copies must mask all but the first six and
last four digits of the account number (PAN) prior to transmission.
Point of Sale
4. Credit card terminals must be batched out daily.
5. Campus merchants (departments) may not store in any form the magnetic strip, which
consists of track data, CVV2 data or PIN data.
6. University Records Retention Policy states that we must retain all credit card receipts for
three years. PCI Standards also require that these records be classified by labeling as
“Confidential” and stored securely. These receipts should not contain the full PAN
(Primary Account Number). At the end of three years they must be properly disposed of
by being cross-cut shredded, incinerated, or pulped. Containers storing documents to
be destroyed should have a lock preventing access to its contents.
7. To process a credit for a point-of-sale terminal, ideally you should have the card present
and swipe it through the terminal. If the card is not present then there should be
communication with the cardholder to get the full number to be used to enter into the
terminal. There should not be storage of full card numbers in any format.
Online
8. Electronic records containing cardholder data should not contain the full PAN. If you
receive a report containing the full PAN please contact your campus eCommerce
representative immediately for instructions on permanently deleting the file.
9. All credits specific to CyberSource applications must be processed online through the
University Treasurer’s Office within 60 days of the original transaction and are based on
a transaction reference number. Card number is not required. Beyond 60 days, credits
can be processed manually by the receiving site or as a stand-alone credit through the
Treasurer’s Office.
4/9/2015
Section B: Inventory
1. Each campus must maintain a complete and accurate inventory of all credit card
processing locations including point of sale and online merchants. The campus is also
responsible for maintaining an inventory of documentation regarding third party
vendors contracted to process credit cards. Process flows and technology configuration
should be documented and updated as needed.
2. Campus E-commerce representatives must be involved in and approve any decisions to
accept credit cards or other electronic form of cash receipts.
3. It is recommended that each campus maintain an inventory of all outsourced vendors
that process credit card payments. Proof of their PCI compliance should be provided
no less than annually.
Section C: PCI Compliance
Administrative
1. Campus E-commerce representatives and Campus Bursars will work with departments
to provide the necessary guidance in the areas of PCI Compliance, internal controls
(including restricting access to cardholder data), deposit techniques and reconciliation.
2. E-commerce representatives have the authority to suspend the account of a merchant
who is not in compliance with the University of Massachusetts Fiscal Standard and
Procedure – E-Commerce and PCI.
3. Failure to follow the PCI DSS standards for credit card merchants subjects the
University to fines and penalties. Any fines will be the responsibility of the campus.
4. Use of any unauthorized or non-compliant third party credit card processing vendors
must be immediately terminated.
5. Any department accepting credit card payments in any format is required to complete
the appropriate PCI SAQ (Self-Assessment Questionnaire) annually.
6. Transmission of quarterly scan results and the annual SAQ will be sent and tracked by
the Treasurer’s Office to the acquiring bank.
29
Appendix
UNIVERSITY OF MASSACHUSETTS TREASURER’S OFFICE
Treasurer’s Fiscal Procedure No. 08-01
Effective Date: March 1, 2008
Fiscal Standard and Procedure – E-Commerce and PCI
Section C: PCI Compliance
Point of Sale
7. All broken and discontinued POS terminals must be returned in a secure manner to the
University Treasurer’s Office for disposal.
8. Departments are responsible for ensuring they only use PCI compliant POS terminals and
must replace any non-compliant or obsolete terminals at their own expense.
9. POS terminals should only be used on campus. If a business need arises to take the
terminal off campus departments must obtain approval from their campus eCommerce
Representative prior to taking a terminal off campus. The requesting department must be
able to confirm the connection type that will be used at the outside venue and agree to
monitor the terminal at all times and keep it securely locked when not in use.
Online
10. CyberSource and NelNet have been identified as the third party vendors of choice for all
online activity. Any deviation from the use of CyberSource or NelNet must be approved by
your campus Vice Chancellor for A&F as well as the E-commerce Committee. All third
party vendors are subject to the same standards for data compliance and security. Proof
of PCI compliance must be provided on an ongoing basis. Proof will be provided no less
than annually.
11. Third party installations other than CyberSource or NelNet must be reviewed by a QSA
(Qualified Security Assessor) prior to accepting payments. The QSA deliverable should be
a written report stating that the installation was installed in a PCI compliant manner.
Additionally, campuses should periodically review these installations to confirm ongoing
compliance.
12. All new payment applications must be listed on the PCI list of Validated Payment
Applications. If the application is not listed the campus must provide the University
Treasurer’s Office with a PABP Implementation Guide to help ensure that once the
application is implemented it is in compliance. This will demonstrate that the application
was developed under PABP guidelines and that their environment is PCI compliant.
13. All charge card applications written in-house must be developed using VISA’s PABP,
Payment Application Best Practices and validated to be PCI compliant before going live.
14. Any department processing online credit card payments must work with their campus IT
Security Department to determine if they will need to complete and submit quarterly
scans.
4/9/2015
Section D: Online Third Party Applications
1. All third party credit card processing vendors are subject to PCI DSS Standards. In
addition they may be subject to quarterly network scans that must be performed
by an Approved Scanning Vendor (ASV). The completion of annual self-assessment
questionnaires is required. It is the responsibility of the campus to monitor and
maintain current documentation.
2. Outside (third party) vendors must be listed on the PCI list of Validated Payment
Applications or if not listed, they need to submit documentation from their QSA to
the campus stating that they are PCI compliant and the date specific to that
compliance. This document must be updated annually.
3. All new contracts with third party or outside vendors must contain language
requiring that the vendor be PCI compliant and they will remain PCI compliant
throughout the term of the contract. If the third party vendor is not the payment
processor, their contract language must state that they will only use a PCI compliant
payment processor throughout the term of the contract. Failure to do so gives the
University the right to terminate the contract at no penalty to the University of
Massachusetts.
4. All new contracts with third party or outside vendors must contain language that
the vendor acknowledges that they are responsible for the security of cardholder
data that they possess.
5. Campuses are responsible for ensuring that third party vendors remain PCI
compliant throughout the term of the contract.
30
Appendix
PCI DSS Terminology
Approved Scanning Vendor (ASV) - is a vulnerability assessment provider who provides
automated software tools for scanning for vulnerabilities.
Cardholder - Non-consumer or consumer customer to whom a payment card is issued to
or any individual authorized to use the payment card.
Cardholder Data - At a minimum, cardholder data consists of the full PAN. Cardholder
data may also appear in the form of the full PAN plus any of the following: cardholder
name, expiration date and/or service code.
Internal Security Assessor (ISA) - The ISA Program provides eligible internal security
audit professionals PCI DSS training and certification that will improve the organization’s
understanding of the PCI DSS, facilitate interactions with QSAs, enhance the quality,
reliability, and consistency of PCI DSS self-assessments, and support consistent and
proper application of PCI DSS measures and controls.
The Payment Application-Data Security Standard (PA-DSS) - A global security standard
created by the Payment Card Industry Security Standards Council, or PCI SSC, formed by
the major credit-issuing companies with the goal of delivering an effective and useful
data security standard to vendors of payment application systems. The intent of this
standard is to effectively prohibit secure data from being illegally accessed by
unauthorized parties.
Payment processor - An organization that processes payment requests, such as credit
card authorizations and settlements, to the appropriate card associations per their
guidelines. Your merchant bank’s processor relationship determines which payment
processor you will use.
Payment gateway - An organization, such as CyberSource, that enables merchants to
securely send and receive order information to and from payment processors in the
appropriate format.
PCI Compliant - refers to an organization that has become compliant with the PCI DSS
and has demonstrated this either through a Self Assessment Questionnaire or through
formal validation (audit) by a QSA firm.
PCI DSS - Data Security Standard – a document consisting of 12 requirements and various
principles all designed to provide a framework to protect payment card data and
systems.
4/9/2015
PCI SSC – Security Standards Council - the global governing body for payment card
security standards. Responsible for developing, managing, education, and awareness of
the PCI Security Standards including Data Security Standard (PCI DSS), Payment
Application Data Security Standard (PA-DSS), and PIN Transaction Security (PTS)
Requirements.
Primary Account Number (PAN) - is essentially a payment card number (16 – 19 digit)
which is generated according to the LUHNS algorithm).
Qualified Security Assessor (QSA) – is a Information Security and PCI expert who works
for a QSA firm and who has been certified by the PCI SSC to be fit and proper to validate
whether a company / environment is PCI compliance
Report on Compliance (ROC) - the report on compliance refers to a report that shows
that an environment has been validated by a QSA in accordance with the PCI DSS. The
outcome of the validation assessment may result in a Report of Compliance opinion of
Compliant or Not Compliant depending the evidence provided to support the
compliance assertions provided by the merchant or service provider to the QSA
Self-Assessment Questionnaire (SAQ) – A validation tool for merchants and service
providers that are not required to undergo an on-site data security assessment per the
PCI DSS Security Assessment Procedures. The purpose of the SAQ is to assist
organizations in self-evaluating compliance with the PCI DSS, and you may be required
to share it with your acquiring bank. There are multiple versions of the PCI DSS SAQ to
meet various business scenarios.
Service Provider - An entity that stores, processes or transmits cardholder data on
behalf of merchants. Examples of service providers include hosting and payment
services for merchants. Such providers do not have direct service provider contractual
relationships with acquiring institutions, other than for their own merchant activities,
but nonetheless still fall into scope for the PCI DSS where they store, process or
transmit payment cards on behalf of merchants. It is the merchant responsibility to
ensure the service providers operate in a way that is complaint with the PCI DSS.
Validation / Audit - refers to the final stage of PCI compliance whereby a Qualified
Security Assessor (QSA) will validate and attest the compliance status of the
environment under assessment for compliance with the PCI DSS.
Vulnerability Assessment – is a technical security audit that uses automated tools to
test for security flaws, mis-configurations and weaknesses in infrastructure and
applications (to a relatively limited extent).
31
Appendix
Useful PCI DSS References
PCI DSS Overview video
(How Thieves Are 'Stealing You)
http://abcnews.go.com/Video/playerIndex?id=4769169
Treasurer’s office e-commerce standards
http://media.umassp.edu/massedu/treasurer/Principles%20--02272008final%20on%20letterhead[1].pdf
PCI Security Standards Council
PCI Quick Reference Guide
Documents Library
Certified devices
Self-Assessment Questionnaires
Prioritized Approach
https://www.pcisecuritystandards.org/
https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf
https://www.pcisecuritystandards.org/security_standards/documents.php?document=2.0#2.0
https://www.pcisecuritystandards.org/security_standards/ped/pedapprovallist.html
https://www.pcisecuritystandards.org/saq/index.shtml
https://www.pcisecuritystandards.org/education/prioritized.shtml
Behind a transaction (Visa)
Visa Cardholder Info Security Program
Bulletins and alerts
http://usa.visa.com/merchants/risk_management/data_security_demo/m1/index.htm
http://usa.visa.com/merchants/risk_management/cisp.html
http://usa.visa.com/merchants/risk_management/cisp_alerts.html
Behind a transaction (MasterCard)
MasterCard Site Data Protection Program
http://media.mastercard.com.edgesuite.net/video_portal/behind-a-transaction.wm
https://sdp.mastercardintl.com/
NelNet Compliance Page
CyberSource PCI Program
http://www.campuscommerce.com/page.cfm?p=398
http://www.cybersource.com/products_and_services/payment_security/pci-101/
Fifth Third bank PCI Compliance Program
http://www.vantiv.com/Products/PCI-Compliance
4/9/2015
32
Appendix
Frequently Asked Questions (FAQs)
General Information
1. What are the Payment Card Industry (PCI) Data Security Standards?
The PCI Data Security Standards are association (Visa®/MasterCard®) and industry mandated
requirements for handling of credit card information, classification of merchants, and
validation of merchant compliance. Merchants are responsible for the security of cardholder
data and must be careful not to store certain types of data on their systems or the systems of
their third party service providers. Merchants are also responsible for any damages or liability
that may occur as a result of a data security breach or other non-compliance with the PCI
Data Security Standards. The information security principles contained within these standards
are based on ISO 27002, the internationally recognized standard for information security
practices.
2. To whom does the Payment Card Industry Data Security Standards Compliance Program
apply?
The program encompasses all merchants and third party service providers that store, process,
or transmit cardholder data.
3. What are the benefits of being in compliance with the Payment Card Industry Data
Security Standards?
It is good business practice to adhere to the PCI standards and protect cardholder
information. Additionally, Visa, MasterCard, and Discover® Network may impose fines on
their member banking institutions when merchants do not comply with PCI Data Security
Standards. You are contractually obligated to indemnify and reimburse us, as your acquirer,
for such fines. Please note such fines could be significant, especially if your business is
compromised and you have not been validated as compliant.
4. What is "cardholder data"?
Cardholder data is any personally identifiable data associated with a cardholder. This could be
an account number, expiration date, name, address, social security number, etc. The account
number is the critical component that makes the PCI Data Security Standards applicable. All
personally identifiable information associated with the cardholder that is stored, processed,
or transmitted is also considered cardholder data. The PCI Data Security Standards apply to all
cardholder data stored, processed, or transmitted.
4/9/2015
Your Compliance Classification Level and What it Means
5. How is a merchant's compliance classification level determined?
A merchant's compliance classification level is determined by annual transaction volume.
The volume calculation done for you will be based on the gross number of Visa,
MasterCard or Discover Network transactions processed within your merchant account.
However, it will not be based on the aggregate transaction volume of a corporation that
owns several chains.
6. How is IP-based POS environment defined?
The point of sale (POS) environment is the environment in which a transaction takes
place at a merchant location (i.e. retail store, restaurant, hotel property, gas station,
supermarket, or other point of sale location). An Internet protocol (IP) -based POS
environment is one in which transactions are stored, processed, or transmitted on IPbased systems, or systems communicating via TCP/IP.
7. What is a "High Risk" merchant?
Currently, merchants that are known to use non-compliant payment applications
(applications known to store magnetic stripe, Cardholder Verification Value (CVV), or
Cardholder Verification Value 2(CVV2) or Card Validation Code 2 (CVC2) or Card
Identification (CID) fall into this "High Risk" category.
8. Can my compliance requirements change?
Yes. As your transaction volume changes, and as association and industry rules change,
your compliance requirements may change. It is your responsibility to be continuously
aware of the data security requirements that currently apply to you.
Data Storage Protocol
9. When is it acceptable to store magnetic stripe data?
It is never acceptable to retain magnetic stripe data subsequent to transaction
authorization. Visa, MasterCard, and Discover Network prohibit storage of the contents
of the magnetic stripe as a unit. However, the following individual data elements may be
retained subsequent to transaction authorization: Cardholder Account Number
Cardholder Name
Card Expiration Date
33
Appendix –Frequently Asked Questions
Frequently Asked Questions (FAQs)
10. Are there alternatives to encrypting stored data?
According to requirement 3.4 of the Payment Card Industry Security Audit Procedures, stored
cardholder data should be rendered unreadable. And, if encryption, truncation, or another
comparable approach cannot be used, encryption options should continue to be investigated
as the technology is rapidly evolving. In the interim, while encryption solutions are being
investigated, stored data must be strongly protected by compensating controls. Any
compensating controls should be considered as part of the compliance validation process.
An example of compensating controls for encryption of stored data is complex network
segmentation that may include the following:
 Internal firewalls that specifically protect the database.
 TCP wrappers or firewall on the database to specifically limit who can connect to the
database.
 Separation of the corporate internal network on a different network segment from
production, with a firewall separation from database servers.
11. Are there compensating controls that can be used to meet a requirement?
If a requirement is not, or cannot, be met exactly as stated, compensating controls can be
considered as alternatives to requirements defined in PCI Data Security Standards.
Compensating controls should meet the intention and rigor of the original PCI Data Security
Standards, and should also be examined by the security assessor as part of the regular PCI
Data Security standards compliance audit. Compensating controls should be "above and
beyond" other PCI Data Security Standards, and should not simply be in compliance with PCI
Data Security Standards.
12. What if a merchant does not store cardholder data?
If a merchant does not store cardholder data, the PCI Data Security Standards still apply to
the environment that transmits or processes cardholder data. This includes any service
providers that a merchant uses.
4/9/2015
Approved Software and Applications
13. What processing software/applications are currently known to be compliant?
Visa has validated several software / applications to be compliant with the PCI Data
Security requirements, including the requirement that after authorization, Security Data
will be purged from the records and systems. Security Data is certain security
information, including the full contents of any track of the magnetic stripe from the back
of a card and the cardholder validation code (the three or four digit value printed on the
signature panel of the card). Copies of these software programs that have version
numbers older (those with a lower version number) than those indicated must be either
upgraded, have a special security patch installed, or be replaced with compliant software
to ensure that you do not store Security Data in violation of Visa, MasterCard or Discover
Network's rules. If you are using any software programs different than the programs
indicated, you must confirm with your software vendor that the version you are using is
compliant with current security requirements.
Steps You Should be Taking
14. What is a security assessor?
A security assessor is an auditing company that specializes in information security. They
use card association developed criteria (the PCI Data Security Standards) to validate
whether or not a merchant's information security is robust enough to sufficiently protect
cardholder data from unauthorized access or malicious parties.
15. Is it a common practice for security assessors to perform a re-assessment?
Yes, assessors frequently are asked to revalidate those items that were not in place at
the time of the initial review and provide an updated Report on Compliance.
16. Where can the PCI Data Security Standards Compliance Questionnaire be found?
The PCI Self-Assessment Questionnaire is available for download on the PCI Data
Security Standards Council website
34
Appendix – Frequently Asked Questions
Frequently Asked Questions (FAQs)
17. What is a System Perimeter Scan?
A System Perimeter Scan involves an automated tool that checks a merchant's or
service provider's systems for vulnerabilities. The tool will conduct a non-intrusive scan
to remotely review networks and Web applications based on the external-facing
Internet protocol (IP) addresses provided by the merchant or service provider. The
scan will identify vulnerabilities in operating systems, services, and devices that could
be used by hackers to target the company's private network. The tool will not require
the merchant or service provider to install any software on their systems, and it will
not perform any denial-of-service attacks.
18. Is the System Perimeter Scan only applicable to e-commerce merchants?
No. The System Perimeter Scan is applicable to all merchants and service providers
with external-facing IP addresses. Even if an entity does not offer Web-based
transactions, there are other services that make systems Internet accessible. Basic
functions such as e-mail and employee Internet access will result in the Internetaccessibility of a company's network. These paths to and from the Internet can provide
unprotected pathways into merchant and service provider systems if not properly
controlled. If a merchant or service provider does not have any external-facing IP
addresses, they will only be required to complete the Report On Compliance or the
Compliance Questionnaire, as appropriate.
19. How do merchants determine the cost of compliance validation?
The cost of the review varies greatly depending on the size of the environment to be
reviewed, the chosen assessor, and the degree to which the merchant is already in
compliance when the review commences. The cost of a System Perimeter Scan
depends on the number of IP addresses to be scanned, the frequency of the scans, and
the chosen assessor.
20. What if a merchant has outsourced the storage, processing, or transmission of
cardholder data to a service provider?
Merchants should deal only with PCI Data Security Standards compliant service
providers. If there are service providers handling cardholder data on a merchant's
behalf, the merchant is still responsible for the security of this data and must ensure
that contracts with these service providers specifically include PCI Data Security
Standards compliance as a condition of business.
4/9/2015
21. Do merchants need to include their service providers in the scope of their PCI Data Security
Standards Review?
Yes. Merchants are responsible for the compliance of their service providers.
22. Can a merchant be considered compliant if they have outstanding non-compliance issues,
but provide a remediation plan?
No. Lack of full compliance will prevent a merchant from being considered compliant. Wells
Fargo encourages merchants to complete the initial review, develop a remediation plan;
complete items on the remediation plan, and revalidate compliance of those outstanding items
in a timely manner.
Penalties for Non-compliance
23. Are there fines associated with non-compliance of the PCI Data Security Standards?
Yes. Visa, MasterCard, and Discover Network may impose fines on their member banking
institutions when merchants do not comply with PCI Data Security Standards. You are
contractually obligated to indemnify and reimburse us, as your acquirer, for such fines. Please
note such fines could be significant.
24. Are there fines if cardholder data is compromised?
Yes. If cardholder data that you are responsible for is compromised, you may be subject to the
following liabilities and fines associated with non-compliance:
 Potential fines of up to $500,000 (in the discretion of Visa, MasterCard, Discover Network or
other card companies).
 All fraud losses incurred from the use of the compromised account numbers from the date
of compromise forward.
 Cost of re-issuing cards associated with the compromise.
 Cost of any additional fraud prevention/detection activities required by the card
associations (i.e. a forensic audit) or costs incurred by credit card issuers associated with the
compromise (i.e. additional monitoring of system for fraudulent activity).
Other PCI Compliance Resources
25. Where can I go online to get more information?
For information on association and industry cardholder information security programs, please
visit the following websites on a regular basis:
 Visa USA — http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html
 MasterCard — https://sdp.mastercardintl.com
 Discover Network — http://www.discovernetwork.com/fraudsecurity/disc.html
 PCI Security Standards Council — https://www.pcisecuritystandards.org
35