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

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

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

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

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 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, 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. 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?source=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 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

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

Identifying, Finding & Eliminating Sensitive Cardholder Data

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

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 Know Your Scope Strive for Consistency and Standardization 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 Jeffrey Sanchez, Managing Director Powerful Insights. Proven Delivery.™