Payment Card Industry
(PCI)
Data Security Standards (PCI-DSS)
Overview
•
•
•
•
Today’s Agenda
Compliance Overview & Validation
Requirements
• Including MasterCard changes
announced June 15, 2009
Managing PCI Compliance Scope
Compliance Challenges & Pitfalls
Maintaining Compliance
•
•
•
•
The Protiviti PCI Practice
PCI Security Standards Council
(SSC):
• Qualified Security Assessor
(QSA)
• Approved Scanning Vendor
(ASV)
• Payment Application QSA (QSA)
Member of Virtualization Special
Interest Group
One of only eight QSAs certified
globally
Has helped larger and smaller
organizations across many industries
to validate compliance and
implement effective security controls
Compliance Overview &
Validation
What is the PCI DSS?
• PCI = Payment Card Industry
– Consortium of payment card vendors (Visa, Discover, etc.)
and other vendors
• DSS = Data Security Standard
– Administrative, procedural, and technical safeguards that apply
to all entities that store, process, or transmit payment card
data
– Spans:
• Information technology (IT) systems and electronic data
• Business processes and physical records
• Contracts and legal agreements
• Business partners and outsourced service
providers
– Industry self-regulation
https://www.pcisecuritystandards.org/
Non-compliance
is still a problem
Retailers Failing to Comply with Credit Card Security Standards
• Despite seven years and many deadlines, Visa reports over 15% of Level 1 and
Level 2 companies have not validated compliance (as of 31 March 2009)
Penalties are Severe
• Companies can be barred from processing credit card transactions, higher
processing fees can be applied; and in the event of a serious security breach, fines
of up to $500,000 can be levied for each instance of non-compliance
htttp://www.internetretailer.com/internet/marketing-conference/80146-compliance-dilemma.html
In case of a compromise, Members proven to be non-compliant or whose merchants or
agents are non-compliant may be assessed:
• Non-compliance fine (egregious violations up to $500k)
• Forensic investigation costs
• Issuer/Acquirer losses
• Unlimited liability for fraudulent transactions
• Potential additional Issuer compensation (e.g., card replacement)
• Dispute resolution costs
• Disclosure costs
Program History
The Payment Card Industry (PCI) standard is a program designed to
protect Cardholder data
In June 2001, Visa developed a robust security audit program (CISP)
In December 2004 the expanded Payment Card Industry (PCI) Data
Security Standard (DSS) was adopted by American Express, Diners
Club, Discover Card, JCB, MasterCard, and Visa USA
September 2006 PCI Security Standards Council Formed
October 15, 2008, PABP program transferred to PCI SSC as PS-DSS
PCI Overview
and/or
is a member of
is a member of
Acquirer
Issuer
provides
processing
services to
Merchant
may or may not
be the same as
issues cards to
Cardholder
uses card to buy
from
Validation Overview
• Self-Assessment Questionnaire (SAQ)
– Management self-assessment of compliance
– Rigor depends on business model and systems environment
• Quarterly Vulnerability Scans
– Conducted quarterly by an ASV
– May apply even if the organization does not conduct Internet
payment card transactions
• On-site Assessment (for organizations higher volumes of card
transactions)
– Conducted annually by a QSA or Internal Audit
– Rigorous on-site validation of compliance
Merchant Levels and
Required Validation
Merchant
Definition
MasterCard Criteria*
Level 1
•
•
•
•
Level 2
•
•
Level 3
•
•
Level 4
•
Onsite
Assessment
Self
Assessment
Network
Security Scan
Deadline
Any merchant that has suffered a hack or an attack
that resulted in an account data compromise
Any merchant having greater than six million total
combined MasterCard and Maestro transactions
annually
Any merchant meeting the Level 1 criteria of a
competing payment brand
Any merchant that MasterCard, in its sole discretion,
determines should meet the Level 1 merchant
requirements to minimize risk to the system
Required
Annually
Not Required
Required
Quarterly
30 June
2005
Any merchant with greater than one million but less
than or equal to six million total combined
MasterCard and Maestro transactions annually
Any merchant meeting the Level 2 criteria of a
competing payment brand
Required
Annually
Required
Annually Until
31 December
2010
Required
Quarterly
31
December
2010
Any merchant with greater than 20,000 combined
MasterCard and Maestro e-commerce transactions
annually but less than or equal to one million total
combined MasterCard and Maestro e-commerce
transactions annually
Any merchants meeting the level 3 criteria of a
competing payment brand
Not
Required
Required
Annually
Required
Quarterly
30 June
2005
All other merchants
Not
Required
Required
Annually
Required
Quarterly
Consult
Acquirer
* Merchant levels are defined per payment brand. Visa and MasterCard merchant levels are of primary relevance to most organizations as these card types often represent the highest volume of
transactions. These merchant level descriptions presented here reflect the revised validation requirements issued by MasterCard on June 15, 2009. Visa merchant levels are similar.
Implications of MasterCard
Validation Requirements
•
Level 2 Merchants must have an on-site assessment by 12/31/2010
– These merchants can no longer use the PCI Self-Assessment
Questionnaire (SAQ)
•
Level 1 and Level 2 Merchants must engage a PCI-certified Qualified
Security Assessor (QSA) to conduct an on-site assessment
– Internal Audit can no longer perform the assessment
•
Many merchants who believe they are compliant may find that they cannot
pass an independent assessment conducted by a PCI QSA
– Higher standards of evidence
– Scoping
– Changes in the environment
Recommendations for Level 2
merchants
Engage a QSA now
– Validate scope decisions
– Walk-through the SAQ
– Confirm checklist of required activities and
associated frequency
– Discuss evidentiary requirement
Do this with the QSA on-site, not remotely
SAQ Validation
•
•
•
Management self-assessment of compliance
SAQ is completed with an Attestation of Compliance to demonstrate
compliance
Detailed guidance on selecting and completing the SAQ is described in
the PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v1.2
SAQ
Validation
Type
Description
SAQ
# of
Questions
1
Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data
functions outsourced. This would never apply to face-to-face merchants.
A
11
2
Imprint-only merchants with no cardholder data storage.
B
21
3
Stand-alone dial-up terminal merchants, no cardholder data storage.
B
21
4
Merchants with payment application systems connected to the Internet, no cardholder
data storage.
C
38
5
All other merchants (not included in descriptions for SAQs A-C above) and all service
providers defined by a payment brand as eligible to complete an SAQ.
D
226
Upcoming Changes
•
Potential MasterCard prohibition on using Remote Key Injection (RKI) to upgrade
Point-of-Sale (POS) encryption and requiring manual procedures instead
http://www.computerworld.com/s/article/9135316/MasterCard_halts_remote_POS_security_upgrades?s
ource=rss_security
•
Phase V of Visa’s Payment Application Security Mandates is effective June 10,
2010
Acquirers must ensure their merchants and agents use only PABP-compliant
applications. A list of payment applications that have been validated against
Visa’s PABP is available at www.visa.com/pabp.
Phase V mandates the use of payment applications that support PCI DSS
compliance, requiring acquirers, merchants and agents to use only those
payment applications that can be validated as PABP-compliant. It is important
to note that the deadline for Phase V is aligned with the Triple Data Encryption
Standard (“TDES”) usage mandate for all Point-of-Sale (“POS”) PIN entry
devices (“PEDs”) to be using TDES to protect PINs. Additionally, all attended
POS PEDs must be evaluated by a Visa-recognized laboratory and approved by
Visa prior to this same date.
•
Version 1.3 or 2.0 of the PCI DSS expected Q4 2010
Managing Compliance
Scope
PCI DSS Scoping
PCI DSS applies to all systems and networks that store, process,
and/or transmit cardholder data, and all connected systems
 Includes networking equipment that transmits cardholder data
(i.e. routers, switches, firewalls, web servers)
 Encrypted cardholder data is still within scope
 Does include all account numbers
Exclusion for systems outside the auth/settlement process that store
fewer than 500,000 records was removed in version 1.2.
Merchants and Service
Provider Scoping
PCI Compliance
 Good network segmentation can reduce the scope
 Review includes networks connected to those that have
cardholder data, unless internal firewalls are implemented and
validated
 Review includes wireless access, even for non-cardholder data
functions, unless there is a firewall between the wireless and
production networks
Merchant Validation Scope
Merchant is responsible for compliance of all systems but validation
scope is focused on systems related to authorization and settlement
where cardholder data is processed, stored, or transmitted:
 All external connections into the merchant network
 All connections to and from the authorization and settlement
environment
 All systems connected to any of the above
Reducing Compliance Scope
Minimizing the scope of and expense of compliance can be achieved through:
– Elimination: Many organizations do not need to store all payment card
information – often the data is stored “because we have always done it that
way”
• Methods such as PAN truncation and hashing can also achieve this
objective
– Tokenization: Implementing tokenization methods can reduce encryption
requirements and the number of systems in-scope
– Segmentation: Isolating cardholder systems with network segmentation
techniques can reduce in-scope systems
– Consolidation: Identifying and eliminating redundant data sets and
consolidating applications and information stores can reduce scope
– Distributed Processing: Processing payment cards across multiple DoingBusiness-As (DBA) entities can be used to separate compliance reporting
– Compensating Controls: Compensating controls that meet the rigor and
spirit of the original DSS requirements but at reduced costs can lessen
compliance costs / burdens
Network Segmentation
Example: Non-Segmented
Network
All devices would be in scope for audit and scans. All devices need to
comply with PCI DSS requirements
PCI DSS Scope
PCI Scan Scope
Network Segmentation
Example: Partially Segmented
Network
Only devices which are within the “PCI Segment” would be in scope and need to comply
with PCI DSS Audit requirements, however all externally accessible systems will still be
in scope for PCI Scan Requirements.
PCI DSS Scope
PCI Scan Scope
Example Encryption
Remediation
Current
Remediated
Internet
CC Intake
CC Intake
Credit Card Entered
CC ENCRYPT
CC Token Returned
T
Token & Encrypted CC
Internet
CC Processing
Various Order
Import
Processes
CC Token Used
Credit Card Flow
CC Processing
Various Order
Import
Processes
Master Database
Encrypted Credit Cards
Credit Card Tokens
Encrypted CC
Database Storage
Database Storage
Settlement Process
Settlement Process
Payment Processor
CC Token Entered
T
CC DECRYPT
Credit Card
Card Processing System
Payment Processor
Card Processing System
Identifying, Finding &
Eliminating Sensitive
Cardholder Data
When is Track Data
Allowed/Disallowed?
Track data:
 Cannot be stored past initial authorization
Elements that are allowed to be stored (name, account number, and
expiration date) should be parsed out and stored appropriately
May (and must) travel over the network:
 Should be encrypted on the internal network
 Must be encrypted outside the internal network
One exception - Issuers may store track data where necessary for
issuing business needs
Compensating Controls
– Assessors can always consider compensating controls (except for
track data storage)
– Compensating controls are “above and beyond” other PCI DSS
requirements
– Compensating controls are applicable to most PCI DSS requirements
– Bottom line:
Must meet the intent and rigor of the original PCI requirement and
would withstand a compromise attempt with the same preventive
force as the original requirement
Refer to Compensating controls worksheet in PCI DSS Audit Procedures.
Maintaining PCI
Compliance
Maintaining PCI Compliance
Three Keys to Success
1. Know Your Scope
2. Strive for Consistency and
Standardization
3. Manage Change
Scoping
• Scope can expand and increase the challenge of maintaining
compliance
– Acquisitions and new business ventures
– Payment card acceptance methods
– New locations
– Updates / releases to POS or application software
• EVERYTHING is in-scope if network is “flat” or inadequately
segmented
• Simplify maintaining compliance by
limiting scope
– Elimination
– Segmentation
– Tokenization
Consistency &
Standardization
•
•
•
Environment Consistency
– Implement a common technology infrastructure – POS, network
architecture, etc.
Process Consistency
– Centralized vs. decentralized execution
– Redundant processes (e.g., change management)
– Manual processes
• Higher probability of failure
• What processes were put in place during with the last assessment?
• What evidence was “manufactured” during the last assessment?
• How could manual processes be “semi-automated?” Workflow tool?
Service Desk tickets?
Document Management
– How is substantiating evidence managed?
Managing Change
• Control “configuration drift”
– File Integrity Monitoring & “Closed Loop” Change Management
– Policy enforcement tools such as Group Policy, Configuresoft,
McAfee EPO, etc.
• Turnover of key personnel
• Compensating controls
– Do the constraints justifying their
use continue to be valid?
• DSS clarifications, SSC guidance,
payment card advisories
The PCI Compliance Program
Maintaining PCI compliance is best achieved by implementing a
Compliance Program
•
Recognize that compliance is not an annual exercise
– The Report on Compliance (ROC) or Self-Assessment Questionnaire
(SAQ)
are used to demonstrate compliance
– Organizations must continuously comply with all requirements
•
Establish clear responsibility and accountability for compliance
– Central person or group should manage compliance across IT and
business functions
– Continuous monitoring of controls and control self-assessment (CSA)
– Promptly recognize events that may impact compliance and implement /
enhance
security controls
•
Implement a single program to manage IT security and compliance across
various requirements (PCI, SOX, HIPAA, ISO 27001 ISMS accreditation, etc.)
Key Contact
Jeffrey Sanchez, Managing Director
400 South Hope Street
Suite 900
Los Angeles, CA 90071
Direct: 213.327.1433
Mobile: 818.481.6961
Fax:
213.327.1590
Jeffrey.Sanchez@protiviti.com
Powerful Insights. Proven Delivery.™