1. Payment Card Industry (PCI)
Data Security Standards (PCI-DSS)

2. The Protiviti PCI Practice
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

3. Compliance Overview & Validation

4. 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

5. 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://
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

6. 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

7. provides processing services to may or may not be the same as
PCI Overview
and/or
Issuer
Acquirer
Merchant
Cardholder
uses card to buy from
is a member of
provides processing services to
issues cards to
may or may not be the same as

8. 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

9. Merchant Levels and Required Validation
Definition
MasterCard Criteria*
Onsite
Assessment
Self
Network
Security Scan
Deadline
Level 1
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
Quarterly
30 June
2005
Level 2
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 Until 31 December 2010
Required Quarterly
31 December 2010
Level 3
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
Required Annually
30 June 2005
Level 4
All other merchants
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, Visa merchant levels are similar.

10. 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

11. 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

12. 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. 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

13. Upcoming Changes
Potential MasterCard prohibition on using Remote Key Injection (RKI) to upgrade Point-of-Sale (POS) encryption and requiring manual procedures instead
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
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

14. Managing Compliance Scope

15. 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.

16. 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

17. 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

18. 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 Doing-Business-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

19. 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

20. 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

21. Example Encryption Remediation

22. Identifying, Finding & Eliminating Sensitive Cardholder Data

23. When is Track Data Allowed/Disallowed?
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

24. 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.

25. Maintaining PCI Compliance

26. Maintaining PCI Compliance
Three Keys to Success
Know Your Scope
Strive for Consistency and Standardization
Manage Change

27. 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

28. 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?

29. 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

30. 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 ISMS accreditation, etc.)

31. Key Contact Jeffrey Sanchez, Managing Director 400 South Hope Street
Suite 900
Los Angeles, CA 90071
Direct:
Mobile:
Fax:
Jeffrey Sanchez, Managing Director
Powerful Insights. Proven Delivery.™