The PCI Security Standards Council. Troy Leach April 2012. About the Council. Open, global forum Founded 2006. Responsible for PCI Security Standards. Development Management Education Awareness. PCI Security Standards. Protection of Cardholder Payment Data. - PowerPoint PPT Presentation
Troy LeachApril 2012 The PCI Security Standards CouncilHello! My name is Troy Leach and I am the Chief Technology Officer of the PCI Security Standards Council.
First let me thank you for inviting me to speak with you today. What we are going to discuss today is important not only for your business, but for the entire global payment chain.
About the CouncilOpen, global forumFounded 2006Responsible for PCI Security StandardsDevelopmentManagementEducationAwareness2The PCI Security Standards Council is an open global forum, launched in September of 2006, for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection.
Very simply, this means that we want to protect not just consumers, but industry players such as merchants, processors, financial institutions, and other organizations that store, process and transmit cardholder data.
The Council is currently responsible for developing and evolving several standards we manage. One of my top priorities is to raise awareness of our standards globally by educating merchants, acquirers, processors and anyone else who stores, transmits or processes payment card data. These are the standards that will help you secure your data.ManufacturersPCI PTSPin Entry DevicesEcosystem of payment devices, applications, infrastructure and usersSoftware DevelopersPCI PA-DSSPayment ApplicationsPCI SecurityMOBILE PAYMENTSMerchants & Service ProvidersPCI DSSSecure EnvironmentsPCI Security StandardsProtection of Cardholder Payment Data3Many of you are already aware of the PCI Security Standards. We know that together these standards provide the best baseline protection for protecting payment account data in your organization.
This is a graphic representation of the suite of standards that we manage; PTS, PA-DSS, P2PE, and the PCI DSS.
As you can see now, it includes everything from point of entry of account data to how the data is processed through secure payment applications.
And most significant is the PCI DSS which is really a solid foundation for a defense in depth security strategy.
Technology Updates: MobileQuestions & Answers
AgendaIndustry EngagementEnvironmental Considerations at a GlanceMarketIncreased interest in adoption of a variety of mobile technologiesAbsence of both traditional controls and standards
PCI SSC ActivityCreate efficient mechanisms for broader engagementEvaluate need to develop standardsFacilitate, when applicable, easier compliance mechanisms
Areas of Focus for MobileDevicesTamper-resistance, Secure Card Readers, POI & P2PEApplicationsRequirements and/or Best Practices for authorization and settlementService ProvidersService provider protection of cardholder data and validationMOBILEPeripheral Device EncryptionThe mobile device is just a conduit. It has no ability to decrypt the encrypted data and therefore will never have access to clear-text account data.New PTS approval class for Secure (Encrypting) Card Readers (SCR)SCR and other POICardholder data is only input using an encrypted solution and transmitted encrypted through a mobile device. Scenario 1: Remove the device from the equationNew PTS approval class for Secure Card ReadersDevice never accesses clear-text PANPTS lab evaluates device, QSA validates implementationLeverage P2PE validation requirements - P2PE+ PTS SCR
Audio connector plugs into the phones headphoneQSA must determine data NOT decrypted on phoneNo PIN entryAlso works on computers any device with an audio input jackMobile Phone Plug-in SCRPlug-in MSR encrypts data on the reader even before it reaches the phone2011 Guidance.
Focused on identifying and clarifying the risks associated with accepting payments via mobile solutions and validating mobile payment acceptance applications to version 2.0 of the PA-DSS. Mobile Update Announcement and FAQ This is why we needed to clarify it and this is what we did to clarify itApplications eligible for PA-DSS are defined as:Those that store, process, or transmit cardholder data as part of authorization or settlement, andAre sold, licensed, or distributed to 3rd partiesClarification was needed - not all applications involved in payments transactions are eligible for PA-DSSThe Council received many questions about PA-DSS eligibilityPA-QSAs submitted PA-DSS reports for assessments of ineligible applications
Additional information on the Councils evaluation of mobile payment acceptance applications designed for communication devices may be found the PCI Security Standards Council Update on PA-DSS and Mobile Payment Acceptance Applications and accompanying FAQ. These resources provide guidance for vendors and merchants using mobile-based payment acceptance applications
The FAQ addresses a number of questions including - the defined categories of mobile payment acceptance solutions - the next steps for evaluating Category 3 applications Where do consumer-facing mobile payment applications and contactless technologies such as NFC fit into this classification And, additional guidance on what does this mean for merchants and vendors? 9Mobile Application CategoriesApplications for category 1 and 2 devices are eligible for PA-DSSApplications for category 3 devices pending development of further guidance and/or standardsCategory 2:Purpose Built POS DevicesCategory 3:General Purpose Smart DeviceCategory 1:PTS Approved PED DevicesMobile Working Group (MWG) Identified and clarified risks associated with accepting payments via mobile solutionsDetermined applicability of PA-DSS for validating mobile acceptance applicationsThree categories for mobile payment acceptance applications to address: The mobile application operating environmentThe ability of a mobile acceptance application to support merchant PCI DSS compliance
Mobile Payment Acceptance Application Category 1 Payment application operates only on a PTS-approved mobile device
Mobile Payment Acceptance Application Category 2 Payment application meets all of the following criteria; i. payment application is only provided as a complete solution bundled with a specific mobile device by the vendor; ii. underlying mobile device is purpose built (by design or by constraint) with a single function of performing payment acceptance; and iii. payment application, when installed on the bundled mobile device [as assessed by the Payment Application Qualifed Security Assessor (PA-QSA) and explicitly documented in the payment applications Report on Validation (ROV)], provides an environment which allows the merchant to meet and maintain PCI DSS compliance Bundled solutions are defined as the validated payment application being provided to the customer together with specific version(s) of both the mobile device and the devices operating system/firmware. Mobile Payment Acceptance Application Category3 Payment application operates on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing
Current Environmental ConcernsRapid development of applicationsLack of traditional controlsToo Many PrivilegesMalicious AppsWi-Fi Sniffing / BlackjackingRadiation of keys and side channel attacksDistribution and persistent connectivityOwnership and use policy
Rapid developmentThe Wild West at the momentNeed to take web application secure coding to mobileMalicious AppsSelf-propagatingPolymorphic malwareTrojans (SMS)Key-loggersToo Many PrivilegesUC-Berkley study shows 1/3 of 940 apps tested requested too much privilege than neededAccess to hardwareAccess to drivers (Bluetooth, 4G) Access to admin settings and library levelAccess to sensitive dataWi-Fi Sniffing / Blackjacking
Radiation of keys and side channel attacksLack of traditional controlsAccess control via VPNEncrypted data at restControlled use by single, identified userPassword-protected devicesManual key entryDistribution and persistent connectivityAbility to infect a larger basis more quickly Ability to exploit a broader group of merchants than previously possibleLimited testing of application prior to distributionAbsence of qualified credentials for developing organization
PTS PED Vendor Solutions Phone is designed and purpose built as a secure deviceBecause secure tamper protected device, may use either SCR or a data key managed similar to PIN keyBy definition does not use off the shelf mobile phones
PTS PED Vendor Solutions
Cradle for phoneMay employ encrypting card reader or usedata key managed similar to PIN key Card readers integrated to PED
The mobile device has access to cleartext cardholder data.Mobile Task Force to provide guidance and/or best practicesExposure of CHD within deviceCardholder data is input using a non-encrypted solution (e.g. manual key entry, non-encrypted card reader, etc.) and transmitted through a mobile device. Application Security within Smart DevicesScenario 2: Guidance/best practices for protecting clear-text PAN within mobile applications Mobile Task Force commenced in JulyEvaluating potential guidance/best practices for mobile payment transactions where account data is input using a non-encrypted solution
Mobile Task Force To examine and provide guidance/best practices for mobile payment transactions for category 3 where account data is input using a non-encrypted solution.
The mobile device has access to clear-text account data.
2012 Guidance Calendar Mobile SCR & P2PE Guidance for Merchants
Mobile Acceptance Best Practices
Mobile SCR & P2PE Guidance for Assessors and Vendors
Roadmap for Category 3 Applications
15Mobile SCR & P2PE Guidance for Merchants Spring 2012