Published on

P2PE and other PCI DSS changes

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  2. 2. Agenda • PCI Standards and Typical Card data flow • Data breaches, Threats and existing Mitigation efforts • P2PE overview and Concept • Benefits • Preparing for P2PE • ControlCase P2PE offerings2
  3. 3. PCI Family of Standards Protection of Cardholder Payment Data Software Developers Merchant & Manufacturers Processors PCI PA – DSS PCI Security PCI PTS PCI DSSPin Entry Devices Payment Application Data Security & Compliance Vendors Standard3
  4. 4. Typical Payment Method Encrypted at Communication Layer Encrypted at Communication Layer Encrypted at Communication Layer Acquirer / PG4
  5. 5. Typical Payment Method May or may not be May or may not be encrypted encrypted CHD CHD Acquirer / PG5
  6. 6. Data Breaches6
  7. 7. Industry groups represented by percent of breaches Source: 2012 data breach investigations report by Verizon7
  8. 8. Top 10 Threat Action Types by number of breaches and records Source: 2012 data breach investigations report by Verizon8
  9. 9. Where should Mitigation efforts be focused?9 Source: 2012 data breach investigations report by Verizon
  10. 10. Addition of member in PCI Family Acquires, Payment Software Gateways Merchant & Manufacturers Developers Software Processors PCI PTS PCI PA – DSS Developers, PCI DSS Pin Entry Payment KIFs Data Security Devices Application Vendors PCI Standard P2PE10
  11. 11. What is PCI P2PE?  It is either a solution or Application.  P2PE Solution A point-to-point encryption solution consists of point-to-point encryption and decryption environments, the configuration and design thereof, and the P2PE Components that are incorporated into, a part of, or interact with such environment.  P2PE Application A software application that is included in a P2PE Solution and assessed per P2PE Domain 2 Requirements, and is intended for use on a PCI-approved point-of- interaction (POI) device or otherwise by a merchant.  P2PE Components Any application or device that stores, processes, or transmits account data as part of payment authorization or settlement, or that performs cryptographic key management functions, and is incorporated into or a part of any P2PE Solution.11
  12. 12. P2PE Concept Encrypted at POI Encrypted at POI Encrypted at POI POI HSM Encrypts data Decrypted by HSM at immediately after P2PE Solution reading Provider Acquirer / PG12
  13. 13. P2PE Concept cont.. Encrypted at POI Encrypted at POI Encrypted at POI PTS devices with SRED (secure HS reading and exchange of M FIPS 140-2 Level 3 data) listed as a (or higher) certified “function provided”. or PCI-approved Acquirer / PG13
  14. 14. Benefits Stakeholders in the payments value chain benefit from these requirements in a variety of ways, including but not limited to the following:  Customers may choose to implement Validated P2PE Solutions in order to reduce the scope of their PCI DSS assessments.  Listed P2PE Solutions have been validated as compliant with the P2PE Standard by P2PE Assessors.  Recognized by all Participating Payment Brands14
  15. 15. Characteristics for Merchants Eligible for Reduced Scope for PCI DSS via P2PE Solutions  Use validated P2PE solution  Never stores, processes, or transmits clear-text account data within their P2PE environment outside of a PCI-approved POI device.  Physical environment controls for POI terminals, third-party agreements, and relevant merchant policies and procedures are in place.  Followed the P2PE Instruction Manual (PIM), provided to the merchant by the P2PE Solution Provider.  Adequately segmented (isolated) the P2PE environment from any non-P2PE payment channels or confirmed that no other channels exist.  Removed or isolated any legacy cardholder data, or systems that stored, processed, or transmitted cardholder data, from the P2PE environment.15
  16. 16. P2PE – Key Points  It is OPTIONAL  P2PE scenarios (e.g. hardware-hardware)  Requires the use of SCDs for encryption and decryption of account data and management of cryptographic keys.  POI devices must be PCI SSC approved PTS devices with SRED (secure reading and exchange of data) listed as a “function provided.”  HSMs must be either FIPS 140-2 Level 3 (or higher) certified or PCI-approved (listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM”).  Applications with access to clear-text account data must undergo validation per all P2PE Domain 2 Requirements16
  17. 17. Relationship between P2PE and other PCI standards (PCI DSS, PA-DSS, PTS, and PIN)  POI devices must meet PIN Transaction Security (PTS) requirements validation.  Cryptographic-key operations for both encryption and decryption environments use key-management practices derived from the PTS PIN Security Standard.  Applications on POI devices meet requirements derived from the Payment Application Data Security Standard (PA-DSS).  The decryption environment is PCI DSS compliant.  P2PE standard does not supersede or replace any requirements in the PCI PIN Security Requirements17
  18. 18. PA-DSS Applicability to P2PE  Applications used within P2PE Solutions may or may not be eligible for PA-DSS validation.  Both are distinct PCI SSC standards with different requirements  Validation against one of these standards does not guarantee or provide automatic validation against the other standard.18
  19. 19. P2PE Domains Domain 1 Encryption Device Domain 2 Domain 3 Management Application Security Encryption Environment Use Approved devices and Secure applications in the Secure environments where protect devices from P2PE environment POI devices are present tampering Domain 4 Domain 5 Domain 6 Transmission between Decryption Environment P2PE Cryptographic Key encryption and Decryption and Device Management Operations Environments Secure decryption environments and decryption Use strong cryptographic Secure operations between keys and secure key- encryption and decryption devices environments management functions19
  20. 20. Domain 1 Environments with Encryption, Decryption, and Key Management within Secure Cryptographic Devices Domain Characteristics P2PE validation P2PE validation Requirements Responsibility Domain 1: • POI is a PCI- 1A Build PCI-approved P2PE Solution Provider Encryption Device approved POI POI devices. Management device. 1B Securely manage Use secure encryption • POI device managed equipment used to devices and protect by solution provider. encrypt account data. devices from tampering. • Hardware encryption performed by device.20
  21. 21. Domain 2 Environments with Encryption, Decryption, and Key Management within Secure Cryptographic Devices Domain Characteristics P2PE validation P2PE validation Requirements Responsibility Domain 2: • Application on a PCI- 2A Protect PAN and Application Vendor Application Security approved POI SAD. device. P2PE Solution Provider Secure applications in 2B Develop and the P2PE • All applications are maintain secure environment. assessed as part of applications. the validated P2PE solution. 2C Implement secure application management processes.21
  22. 22. Domain 3 Environments with Encryption, Decryption, and Key Management within Secure Cryptographic Devices Domain Characteristics P2PE P2PE validation validation Responsibility Requirements Domain 3: • No storage of CHD after 3A Secure POI P2PE Solution Provider Encryption transaction processes are devices throughout Environment complete. the • Within the segmented device lifecycle. Secure applications P2PE environment, no in the P2PE CHD stored, processed, or 3B Implement environment. transmitted through secure device channels or methods management external from an approved processes. SCD. • All device-administration 3C Maintain P2PE and cryptographic Instruction Manual operations are managed by for solution provider. merchants. • The P2PE Instruction Manual (PIM) for22 merchants, with instructions on how to implement and
  23. 23. Domain 4 Environments with Encryption, Decryption, and Key Management within Secure Cryptographic Devices Domain Characteristics P2PE validation P2PE validation Requirements Responsibility Domain 4: • All decryption Segmentation operations managed between Encryption by solution provider. and Decryption • Merchant has no Environments access to the Domain 4 has no applicable requirements for encryption this hardware/hardware scenario. Segregate duties and environment (within functions between POI device) or encryption and decryption decryption environment. environments. • Merchant has no involvement in encryption or decryption operations.23
  24. 24. Domain 5 Environments with Encryption, Decryption, and Key Management within Secure Cryptographic Devices Domain Characteristics P2PE validation P2PE validation Requirements Responsibility Domain 5: • Decryption 5A Use approved P2PE Solution Provider Decryption environment decryption devices. Environment and implemented at and Device Management managed by solution 5B Secure all provider. decryption systems and Secure decryption • Merchant has no devices. environments access to the and decryption decryption 5C Implement secure devices. environment. device management • Decryption processes. environment must be PCI DSS compliant. 5D Maintain secure decryption environment.24
  25. 25. Domain 6 Environments with Encryption, Decryption, and Key Management within Secure Cryptographic Devices Domain Characteristics P2PE validation P2PE validation Requirements Responsibility Domain 6: P2PE • All key- 6A Use secure encryption P2PE Solution Provider Cryptographic management methodologies. Key Operations functions implemented and 6B Use secure key generation Use strong managed by methodologies. cryptographic solution provider keys 6C Distribute cryptographic and secure key- • Merchant has no keys in a secure manner. management involvement in key functions. management 6D Load cryptographic keys in operations a secure manner. 6E Ensure secure usage of cryptographic keys. 6F Ensure secure25 administration of cryptographic keys.
  26. 26. At a Glance – Illustration of a typical P2PE Implementation and Associated Requirements26
  27. 27. Developing and Validating a P2PE Solution Note: Domain 4 is greyed out in the diagram below as there are no applicable27 requirements in this Domain for the current phase of P2PE.
  28. 28. Overview of P2PE Solution Validation Processes The P2PE Solution Provider selects a P2PE Assessor The P2PE Solution Provider then provides access to the P2PE Solution to the P2PE Assessor The P2PE Assessor determines the scope and assesses key-injection facilities, Certification Authorities and others, Device, Applications Preparation of P-ROV and P-ROV (if applicable) and submitting to PCI SSC for Review Review of P-ROV and Application P-ROV (if applicable) by PCI SSC28
  29. 29. How to Prepare for P2PE Assessment Prepare following 1. Be ready with approved POI Devices, HSM 2. List of applications used 3. Detailed cryptographic key matrix 4. P2PE Instruction Manual 5. Implementation Guides for applications assessed against Domain 2 6. Key-management procedures and 7. Change control documentation29
  30. 30. Revalidation of P2PE  Yearly Interim Assessment (Healthcheck)  Full Re-assessment after 2 years30
  31. 31. ControlCase P2PE offerings  Guidance on designing P2PE Solutions  Review of P2PE Solution design  Guidance on preparing the P2PE Instruction Manual  Pre-assessment (“gap” analysis) services  Guidance for bringing the P2PE Solution into compliance with the P2PE Standard if gaps or areas of non-compliance are noted during the assessment.  Certifying P2PE solutions and Applications31
  32. 32. Questions And Answers32
  33. 33. Thank You33